libfactory-devel — Developer discussion list

Re: okay, back to the factory

[martin f k. <ma...@ma...>]

While I do not have much time to reply right now, I would like you
to know that boost's factory 3 is looking very awesome. And it's
header-only, so maybe you should just bite the bullet.

It's soo good that I am considering dropping libfactory++ (which
has no real users anyway, as far as i know).

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
i'm currently out trying to find myself.
if i should get back before i return,
please keep me here.

okay, back to the factory

[stephan b. <st...@s1...>]

Hi, martin!!!

i'm working over the internal factory layer for s11n, and here's what i 
would like to try out:


Let's hash out a basic factory *interface*. Internally in s11n, we will 
use that interface. For example, when an s11n'd class registers with 
the s11n factory layer, it would do the equivalent of:

s11n::cl::register_factory<MyInterface>("MyType", my_factory );

Internally, that would use an instance of this base interface. The 
instance of course can do what it likes. Essentially, this is a Policy 
behaviour, but it would in theory be runtime-defined, and i definitely 
don't want the client having to know if they're using cllite or libfac, 
for example. The fact that cllite is a "public" part of the s11n 1.0 
API has come back to haunt me when it comes around to porting my 
1.0-based clients on to 1.1 (which doesn't have cllite, but my clients 
use it for their own purposes).

Basically what i think we need is an interface for the following 
features:

a) register factory functions (or functors) in the form of a key-value 
pair. Experience suggests that the key type is a String 99% of the 
time, but that other types are occasionally useful. i honestly don't 
have a strong preference for whether the core interface hard-codes the 
key as std::string or templatizes it.

b) query factory to see if it has a class, without having to instantiate 
it. This is useful in allowing the factory manager to search for DLLs 
in advance. e.g.

 bool gotit = factory_mgr::instance<MyInterface>().has_class("Foo");

The factory impl could potentially check for DLLs at this point, but to 
correctly do so the factory has to have a non-const has_class() or 
mutable internal data and a quasi-bogus const qualifier on has_class(). 
Whether or not we can truly enforce const behaviour on a factory is 
another point entirely - at this point i don't believe it is really 
possible, due to the inherently backwards nature of the registration 
process, in which any thread may inject classes into the factory at any 
given time.

c) A create()-like function. Whether or not the base interface specifies 
exception guarantees here needs to be defined, as would a base 
exception type. cllite, for example, normally returns NULL on error but 
a toggle can be set to enable a throw cl_exception on a failed 
create(), which allows it to report more specific errors, like 
informative messages direct from dlerror().

d) A destroy()-like function, BUT i do not believe it is realistic to 
require the user to call it. We can't, for most practical reasons, 
because client software which creates objects is often several layers 
removed from the factory, and has no way of getting to it.


Of those features, i think (a) and (c) are the only critical ones. The 
has_class() idea is theoretically useful, and not critical to the 
interface. (d) is a point who's importance i know you and i disagree 
on, but i think you agree with me that we can't expect a client to have 
a direct connection with the factory layer (i also agree with you that 
destroy() is technically the right thing to do, but i think the 
dependency problem clearly outweighs that).


The exact registration techniques/macros used is irrelevant for our 
purposes. i'm only looking for an interface (or interfaces) which i can 
publish in the s11n factory layer, without tying s11n clients to a 
specific underlying factory layer. They should be able to, for example, 
pop in their own implementation of our basic interface. Whether or not 
this requires compile-time knowledge (i.e., is templatized) or can 
truly be done at runtime, i'm still uncertain. Both have their 
potential problems.

Last summer i worked briefly on such an interface, but gave up on it for 
reasons i don't remember. The goal at the time was the same, however - 
hiding from s11n the detail of which underlying factory manager it 
uses.

Before i make a concrete proposal, is there anything specific i haven't 
addressed, or where you feel i'm off base? i'd especially like to hear 
your ideas on exceptions, when to throw them, exact scope of the 
interface (for example, DLL lookups don't belong in it).

i'm going to spend part of tonight going over libfac, and refreshing my 
memory of how you handled non-default ctors. That is a feature i would 
eventually like to get in to s11n.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: refining the factory model

[stephan b. <st...@s1...>]

On Wednesday 29 December 2004 06:51, martin f krafft wrote:
> It would be extremely useful if you'd just include libfactory
> straight, instead of creating YAFF (Yet Another Factory Framework).

i can't use libfac as long as we have the client-must-call-destroy() 
approach, as lib level code using libfac can't enforce that in clients 
creating objects through the lib.


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: refining the factory model

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.12.28.1745 +0100]:
> As part of the pclasses.com/s11n.net colaboration, Christian
> Prochnow (project lead) asked me if i would like to rewrite their
> Factory layer for their 1.x =3D=3D> 2.x rewrite. Maybe they were just
> kidding, but i happily accepted. i looked over their Factory
> implementation, then took what i learned from their code and
> applied it to the basic model laid out by s11n's factory.

It would be extremely useful if you'd just include libfactory
straight, instead of creating YAFF (Yet Another Factory Framework).

That said, I will not look at the code now as I am reading this over
an ass-slow GSM link.

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
"you know you're a hopeless geek when you misspell 'date' as 'data'"
                                                   -- branden robinson

refining the factory model

[stephan b. <st...@s1...>]

Yo, libfactory!

martin, i know you're on holiday, but i want to go ahead and send this 
while i'm thinking about it...

As part of the pclasses.com/s11n.net colaboration, Christian Prochnow 
(project lead) asked me if i would like to rewrite their Factory layer 
for their 1.x ==> 2.x rewrite. Maybe they were just kidding, but i 
happily accepted. i looked over their Factory implementation, then took 
what i learned from their code and applied it to the basic model laid 
out by s11n's factory.

So far, i'm extremely pleased with the results. i've gotten some great 
re-use out of the Factory class in the rest of the P tree, replacing 
the various P1.x Factories/PluginManagers with simple subclasses or 
typedefs of this implementation. Currently it provides the plugin 
support for MimeTypes, Serializers, and arbitrary client-side types, 
and will later support the IOManger layer, to dispatch to i/o handlers 
based on URL protocols.

Attached is what the base factory looks like. i've also included a 
couple supplemental headers it currently needs.

You'll notice that it doesn't have dll support. That's all fine and 
good, because clients can plug in their own by providing a template 
specialization of FactoryInstanceHook<FactoryT>. This how i've done it 
in the P tree: the DLL-aware layer (not part of the core module) plugs 
in it's own handler, such that Factory<T>::instance() returns a 
DLL-aware Factory instance.

The factory registration supermacro is in FactoryReg.h.

i really like P's "SharedLib" abstraction, and will implement something 
similar to abstract away the platform-specific details of opening a DLL 
for libfactory. P currently supports 5 or 6 different DLL loaders using 
their model, and i believe i can support libltdl, libdl and Win32 (the 
others are obscure platforms i won't have access to).

Please give a look to the Factory class and let me know if this seems 
like a usable model for libfactory. As part of s11n 1.1 i will be 
cleaning up the factory interface so we can plug in libfac to it.

See ya!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: questions about libkdtree++

[martin f k. <ma...@ma...>]

also sprach Matthew Papakipos <ma...@pa...> [2004.12.03.0154 +0100]:
> i'm looking at wrapping this so i can use it inside perl.  has anyone don=
e this
> already?

No, but I would suggest using swig (www.swig.org) to generate the
wrappers automatically. This should be rather trivial.

Anyway, I would be very happy to have some perl wrappers and could
give you access to the code repository to host them!

> in test_kdtree.cpp
> am i correct in assuming that find_within_range finds all points within 3
> distance-squared from s?

Well, actually it's all the points within the hypercube around s, so
not the hypersphere.

> when the iterator is subsequently used, does it get the points in
> order of increasing distance from s?

No.

> is there an efficient way to get an iterator that will iterate
> through all points in order of increasing distance from s?  (i'll
> cut off the search once i find what i'm looking for to be fast).

There is a new function in CVS to get the nearest point, written by
Paul Harris. I am sure this can be extended in the way you need it.

Please subscribe to libkdtree-devel and libkdtree-announce, and then
write any further questions to the the -devel list.

Thanks,

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
"literature always anticipates life.
 it does not copy it, but moulds it to its purpose.
 the nineteenth century, as we know it,
 is largely an invention of balzac."
                                                        -- oscar wilde

Re: repos

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.10.07.2310 +0200]:
> You're quickly getting into the realm of DLL-based symbol lookups
> (dlsym()), which are error prone and not type-safe.

Well, this is going to be unavoidable if we want to design such
a software, right?

We *could* introduce a registration file format that libraries have
to provide to be used by libdlfactory++. Of course, this would mean
that we add an extra hurdle to the deployment for libdlfactory++.
Sort of like pkg-config, but with actual usability impacts.

> i think you're right on track, except that i'm still fuzzy on the
> line between module loader and dll loader. i haven't yet grasped
> the conceptual difference between the two: they seem to be the
> same (or very, very similar) to me. Can you clear that up for me?

Well, I see the line between the factory, the module loader, and the
DLL finder. The DLL's finder's job is simply to locate the DLL which
provides the requested functionality. The module loader then loads
this DLL and registers it with the factory. Does that make sense?

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
normaliser unix c'est comme pasteuriser le camembert.

Re: repos

[stephan b. <st...@s1...>]

On Thursday 07 October 2004 23:10, stephan beal wrote:
> 	open_dll( "foo"[, "optional:PATH:list"]" );

Sorry, i was a bit misrepresentative there: the current cllite code does 
not accept the path as a second arg, but allows you to modify the path 
via an object returned via cllite::class_path(). It would be a 5-line 
addition to allow the path to come in as a second argument.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: repos

[stephan b. <st...@s1...>]

On Saturday 02 October 2004 14:33, martin f krafft wrote:
>   libdllfinder++ (or maybe libsofinder++)
>   libmodloader++
>
> The first exports an API to search the filesystem for a DLL that
> exports certain functionality. 

You're quickly getting into the realm of DLL-based symbol lookups 
(dlsym()), which are error prone and not type-safe.

> It should be able to take a class 
> name (which we can translate to the class constructor and search for
> the function), and it should be able to use
>
>   - a config file specifying paths
>   - an environment variable of paths
>   - a path list in the function invocation

cllite provides all but the first. It could trivially provide the first 
using s11n, but that would introduce a cyclic dependency between the 
two. Thus... cllite could do the first with some custom config file 
code.


> to search. The return value should be the absolute filesystem path
> of the DLL defining the class, or it throws an exception otherwise.

What's the use of a search path if you're gonna require absolute file 
paths? Two problems:

a) You've got to allow for search paths, (as you said above).

b) Requiring the ".dll" or ".so" extension to be provided by the client 
means the client has to know what platform he's on. In my experience 
moving this into an #ifdef block in the dll loader is much more 
convenient for the client.

Allowing the client to pass a base name is, IMO, an ideal solution for 
DLL lookups, for several reasons. First, let's look at a typical 
client-side call:

	open_dll( "foo"[, "optional:PATH:list"]" );

That would find, depending on the platform:

.\foo
./foo
.\foo.dll
./foo.so
c:\windows\system32\foo
c:\windows\system32\foo.dll
/usr/lib/foo
/usr/lib/foo.so
/usr/local/lib/foo
/usr/local/lib/foo.so

(i'm going off of cllite's behaviour here.)

The reason that ./foo would match is simple: if the client passes 
"foo.so", we want that to match. For that to happen, we have to allow 
for the case that the user has provided a full filename, and does not 
rely on the automatic extension lookup. i will agree that this 
behaviour is arguable, and that it could/should be made policyable. In 
practice it's never failed me, but i will admit that the possibility of 
error is there, e.g., when ./foo or /usr/lib/foo is a directory, a 
binary, or some other type of file.

For the implementation of the class which does these lookups, see  
path_finder.?pp in the class_loader source tree. It supports a list of 
extensions, like a search path: ".so:.SO:.mylib:.whatever"


> First, we must check if (a) such work already exists, and (b)
> whether it is possible at all. Remember that mangling it a bitch,
> but you probably know this much better than I do.

Amen, brother. We won't dwell on that point. :) Brrrrr....

> The second library then merely loads the DLL at runtime, registers
> the class with libfactory++ and makes the user happy. It can either
> just use the class name to identify the builder in the registry or
> generate a unique name on the fly. I guess both should be possible,
> and with the latter, it should be possible to use other types for
> the index than std::string.
>
> What do you think?

i think you're right on track, except that i'm still fuzzy on the line 
between module loader and dll loader. i haven't yet grasped the 
conceptual difference between the two: they seem to be the same (or 
very, very similar) to me. Can you clear that up for me?

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

repos

[martin f k. <ma...@ma...>]

Stephan: about our plans to provide dynamic module loading
compatible to libfactory++.

Instead of libdlfactory or librefactory, I think what we want
instead is two new libraries and leave libfactory++ as it is:

  libdllfinder++ (or maybe libsofinder++)
  libmodloader++

The first exports an API to search the filesystem for a DLL that
exports certain functionality. It should be able to take a class
name (which we can translate to the class constructor and search for
the function), and it should be able to use

  - a config file specifying paths
  - an environment variable of paths
  - a path list in the function invocation

to search. The return value should be the absolute filesystem path
of the DLL defining the class, or it throws an exception otherwise.

First, we must check if (a) such work already exists, and (b)
whether it is possible at all. Remember that mangling it a bitch,
but you probably know this much better than I do.

The second library then merely loads the DLL at runtime, registers
the class with libfactory++ and makes the user happy. It can either
just use the class name to identify the builder in the registry or
generate a unique name on the fly. I guess both should be possible,
and with the latter, it should be possible to use other types for
the index than std::string.

What do you think?

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
                                                       -- mark twain

using phoenices in the registry

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.10.01.2310 +0200]:
> If you like, move this thread over to libfac and i'll follow it from=20
> there (doesn't make a difference to me).

Herewith done.

For reference, this is a cross-entry to

http://sourceforge.net/mailarchive/forum.php?thread_id=3D5682446&forum_id=
=3D39226

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
die wahrheit ist selten
auf seiten der wahrscheinlichkeit.
                                                 -- heinrich v. kleist

Re: Registrar question... bug?

[stephan b. <st...@s1...>]

On Tuesday 01 June 2004 15:46, martin f krafft wrote:
> it's also a bad idea... considering the allocators... to change the
> builder once objects are created...

That's a detail i hadn't considered. Excellent point. You'd have no 
guaranty of getting the matching destructor.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: Registrar question... bug?

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.06.01.1447 +0200]:
> On Tuesday 01 June 2004 14:16, martin f krafft wrote:
> > What's the difference between what you want and what I do with the
> > macros? The registrars are created in anonymous namespaces...
> > aren't they?
>=20
> namespace Factory
> {
>   template <typename _Key, typename _BaseType, typename _SubType =3D=20
> _BaseType,
>             typename _Builder =3D Builder<_BaseType, _SubType> >
>     class Registrar
>     {
> ...

that's the class. not the instance. i doubt you can get ODR problems
with class definitions.

> > So we should add an error policy, or figure out a way to make
> > this a compiler error. like using static asserts. i'd like that
> > the most.
>=20
> That's an interesting idea. As a user i would expect to be able to
> register whenever i want, so i think a policy would be the better
> route. Or simply removing the static one-time check and taking the
> last-reg-takes-effect policy. i can't see a reason to keep people
> from changing the registrations at arbitrary times. That said,
> that's not something people will do, i think. In practice, i've
> never changed factories at runtime.

it's also a bad idea... considering the allocators... to change the
builder once objects are created...

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: kra...@ai... mad...@ma...
=20
"m.c.s.e": minesweeper consultant & solitaire expert

Re: Registrar question... bug?

[stephan b. <st...@s1...>]

On Tuesday 01 June 2004 14:16, martin f krafft wrote:
> What's the difference between what you want and what I do with the
> macros? The registrars are created in anonymous namespaces...
> aren't they?

namespace Factory
{
  template <typename _Key, typename _BaseType, typename _SubType = 
_BaseType,
            typename _Builder = Builder<_BaseType, _SubType> >
    class Registrar
    {
...



> I doubt you want the class to be in an anonymous namespace...

Perhaps not, but for s11n i had horrible problems with 
non-anonymous-namespace registrars and .hpp files. i kept getting ODR 
violations unless i was *really* careful with class registration 
placement.

> > My main concern is the possible end-user confusion when he
> > registers 2 keys for the same type. As a user i would expect the
> > LAST-run registration to take effect, but in fact only the
> > first-run registration would happen.
>
> So we should add an error policy, or figure out a way to make this
> a compiler error. like using static asserts. i'd like that the most.

That's an interesting idea. As a user i would expect to be able to 
register whenever i want, so i think a policy would be the better 
route. Or simply removing the static one-time check and taking the 
last-reg-takes-effect policy. i can't see a reason to keep people from 
changing the registrations at arbitrary times. That said, that's not 
something people will do, i think. In practice, i've never changed 
factories at runtime.



-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: Potential problem in Builder: invalid object copy

[stephan b. <st...@s1...>]

On Tuesday 01 June 2004 14:17, martin f krafft wrote:
>   (a) a compiler error
>   (b) a runtime error
>
> (b) should be avoided at all cost. (a) should be promoted.

Amen, brother!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

last line from irc:

[stephan b. <st...@s1...>]

[14:39:31] <s11n> there's not much which can be removed, as far as 
templates go. i've removed 2 internal layers already, but that didn't 
affect compile times at all.
[14:39:38] <madduck> anyhow. i am gone now. mail me for anything else...
[14:39:40] <s11n> the [partial] tmpl specializations eat up the 
compiler.
[14:39:40] madduck [~ma...@ab...] has left #madduck :
[14:39:48] <s11n> doh!

i'm off to meet my new roommate soon. i don't know if i'll be back 
online tonight or not - i haven't slept in 24 hours, so i may go 
directly to bed tonight. Then again... who knows. In any case, i'll 
continue with the docs. Thanks for the write access.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: Potential problem in Builder: invalid object copy

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.06.01.1242 +0200]:
> Builder<AType,BType> bob;
>=20
> CType c;
> AType * a =3D bob.build( c );
>=20
> Doh! Undefined copy behaviour!

a compile time error, right?

> Also, it just occurred to me: all of the copy-based funcs are of
> course going to require that the type be Copyable, which may not
> be the case for some types. Many types which are
> default-constructable are not copyable. zB, singletons come to
> mind. It is also possible that BaseT implements Copyable but SubT
> does not, in which case such a call would fail... luckily, at
> compile time.

yeah, that's fine. if you try to do things with the library that you
should not, two things can happen:

  (a) a compiler error
  (b) a runtime error

(b) should be avoided at all cost. (a) should be promoted.

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: kra...@ai... mad...@ma...
=20
(on the statement print "42 monkeys"+"1 snake") btw,
both perl and python get this wrong.
perl gives 43 and python gives "42 monkeys1 snake",
when the answer is clearly "41 monkeys and 1 fat snake".
                                                         -- jim fulton

Re: Registrar question... bug?

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.06.01.1248 +0200]:
> > Yes, you are correct. It should probably be static.
> >
> > But then again, there's a problem because then it needs to be
> > initialised, and since libfac is header-only...
>=20
> Eeeek... i can see where this is heading. That's the reason that
> s11n's registration objects are in anonymous namespaces: to allow
> such initialization without ODR violations. i banged my head for
> days trying to figure that out, though. Maybe the Registrar should
> be moved into an anonymous namespace?

What's the difference between what you want and what I do with the
macros? The registrars are created in anonymous namespaces...
aren't they?

I doubt you want the class to be in an anonymous namespace...

> > I think I considered that and chose to make the builder
> > non-static because the size overhead is zero and it's not like
> > you'll create one million registrars for the same type combo.
> > or?
>=20
> i think you're right.
>=20
> My main concern is the possible end-user confusion when he
> registers 2 keys for the same type. As a user i would expect the
> LAST-run registration to take effect, but in fact only the
> first-run registration would happen.

So we should add an error policy, or figure out a way to make this
a compiler error. like using static asserts. i'd like that the most.

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: kra...@ai... mad...@ma...
=20
"man soll nicht in kirchen gehn, wenn man reine luft atmen will."
                                                 - friedrich nietzsche

Re: Registrar question... bug?

[stephan b. <st...@s1...>]

On Tuesday 01 June 2004 12:37, martin f krafft wrote:
> also sprach stephan beal <st...@s1...> [2004.06.01.1221 +0200]:
> > am i correct in thinking that the key 75 would never be registered,
> > because of this check in the ctor:
> >
> >         _S_reg() = _S_reg() || _Factory::register_builder(__KEY,
> > _M_builder);
>
> Yes, you are correct. It should probably be static.
>
> But then again, there's a problem because then it needs to be
> initialised, and since libfac is header-only...

Eeeek... i can see where this is heading. That's the reason that s11n's 
registration objects are in anonymous namespaces: to allow such 
initialization without ODR violations. i banged my head for days trying 
to figure that out, though. Maybe the Registrar should be moved into an 
anonymous namespace?

> I think I considered that and chose to make the builder non-static
> because the size overhead is zero and it's not like you'll create
> one million registrars for the same type combo. or?

i think you're right.

My main concern is the possible end-user confusion when he registers 2 
keys for the same type. As a user i would expect the LAST-run 
registration to take effect, but in fact only the first-run 
registration would happen.

> maybe, however, the initialisation of the default builder can be
> done in the macros?

i think it can only safely be done if it's in an anonymous namespace, 
otherwise ODR violations will (may?) become a problem. i had all kinds 
of headaches with this early on in s11n_CL's development. The anonymous 
namespaces, while not "pretty", offered a great solution - in fact, the 
only useful solution i know of.


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Potential problem in Builder: invalid object copy

[stephan b. <st...@s1...>]

      inline _BaseType*
      build(_BaseType const& __THAT) const {...}

Let's say i've got:

Builder<AType,BType> bob;

CType c;
AType * a = bob.build( c );

Doh! Undefined copy behaviour!

Also, it just occurred to me: all of the copy-based funcs are of course 
going to require that the type be Copyable, which may not be the case 
for some types. Many types which are default-constructable are not 
copyable. zB, singletons come to mind. It is also possible that BaseT 
implements Copyable but SubT does not, in which case such a call would 
fail... luckily, at compile time.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: Registrar question... bug?

[martin f k. <ma...@ma...>]

also sprach stephan beal <st...@s1...> [2004.06.01.1221 +0200]:
> can't _M_builder be static?

I'd say so.

> Registrar<int,Foo,Bar>( 42 );
> Registrar<int,Foo,Bar>( 75 );
>=20
> am i correct in thinking that the key 75 would never be registered,=20
> because of this check in the ctor:
>=20
>         _S_reg() =3D _S_reg() || _Factory::register_builder(__KEY,=20
> _M_builder);

Yes, you are correct. It should probably be static.

But then again, there's a problem because then it needs to be
initialised, and since libfac is header-only...

I think I considered that and chose to make the builder non-static
because the size overhead is zero and it's not like you'll create
one million registrars for the same type combo. or?

maybe, however, the initialisation of the default builder can be
done in the macros?

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
=20
"sometimes we sit and read other people's interpretations of our
 lyrics and think, 'hey, that's pretty good.' if we liked it, we would
 keep our mouths shut and just accept the credit as if it was what we
 meant all along."
                                                        -- john lennon

Registrar: uninitialized static var

[stephan b. <st...@s1...>]

bug?

static Registrar _S_instance;

is apparently never initialized. For that matter, it's never used. Can 
it go away?

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Registrar question... bug?

[stephan b. <st...@s1...>]

=46rom Registrar:

    private:

      static bool&
      _S_reg()
      {
        static bool __reg =3D false;
        return __reg;
      }

      static Registrar _S_instance;

      _Builder const _M_builder;


can't _M_builder be static?

After all, "es kann nuer einen Geben" for each BaseType/SubType/KeyType=20
combination.

Using the current code, calling the following 2 funcs would, i *think*=20
end up with the same effect as a static _M_builder:

Registrar<int,Foo,Bar>( 42 );
Registrar<int,Foo,Bar>( 75 );

am i correct in thinking that the key 75 would never be registered,=20
because of this check in the ctor:

        _S_reg() =3D _S_reg() || _Factory::register_builder(__KEY,=20
_M_builder);




=2D-=20
=2D---- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

just FYI: i'm sub'd

[stephan b. <st...@s1...>]

If you prefer to move our "spamming session" over to the list please 
feel free to do so. :)

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts