libfunutil-devel — development forum for libfunUtil

[fU] Fwd: for libfun

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

i *think* i've resolved the qmake problems. AFAICS, it was not 
specifically a deps problem, but a problem in "target propogation": 
when i replaced the eval-based makefile code with non-eval equivalents 
(make < 3.80 does not support eval) i left out the part which passes 
on, e.g., the clean target calls to the qmake files, so the qmakes were 
never getting to clean up (among other things).



----------  Forwarded Message  ----------

Subject: for libfun
Date: Tuesday 09 December 2003 22:17
From: stephan beal <st...@s1...>
To: st...@ei...

Regarding qmake deps:

In qmake2make the deps are appended to make.foo using mkdeps, including
 moc deps, which get pulled from make.foo before we append to it, like
 so:

# the following dependencies were added by
 ../../toc/make/qmake2make.make ClassLoader.o: ClassLoader.cpp \
   /home/stephan/cvs/libfunutil/include/fun/ClassLoader.h \
   /home/stephan/cvs/libfunutil/include/fun/LoadableClass.h \
   /usr/include/string.h \
...
moc_ConfigFile.o: moc_ConfigFile.cpp \
   ConfigFile.h \
   /usr/lib/qt3/include/qmetaobject.h \
   /usr/lib/qt3/include/qapplication.h \
...

touching my config.h, for example, causes a rebuild of Fudgeish.cpp and
StringTokenizer.cpp.

In short, i can't reproduce the broken deps. Have you got a case i can
 try out? IIRC (the mail is on my work PC), you said you were
appending .toc.C_DEPS.make to make.foo (or similar?), which should be
 what's already happening (as C_DEPS becomes obsoleted by the
 qmake2make-gen'd deps). The generated make.foo doesn't (can't, really)
 include .toc.C_DEPS.make, so those deps normally aren't in that
 makefile. Thus qmake2make does the same thing and appends them, with
 the additional feature that generates deps for mocs which C_DEPS
 cannot do if the mocs don't exist when it is run (meaning the
 first-time build).


--
----- st...@s1...
http://s11n.net                     - http://stephan.rootonfire.org
http://qub.sourceforge.net          - http://toc.sourceforge.net
http://countermoves.sourceforge.net - http://libfunutil.sourceforge.net
ad nauseum...

[fU] precomp headers

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

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20Headers


The info available via searching gcc.gnu.org appears to be limited to bug reports.

According to these docs:
"To create a precompiled header file, simply compile it as you would any other file,
if necessary using the -x option to make the driver treat it as a C or C++ header file."

but when i do that with gcc 3.3 i get:
stephan@cheyenne:~/cvs/libfunutil/lib/cl> g++ -pipe -O2 -DNDEBUG=1 
 -I../../include -I/usr/lib/qt3/include -DHAVE_CONFIG_H=1   -c -o foo.pch class_loader.h
g++: compilation of header file requested

Ah... here we go:
g++ -pipe -O2 -DNDEBUG=1    -I../../include -I/usr/lib/qt3/include -DHAVE_CONFIG_H=1  -xc++ -c -o foo.pch class_loader.h
stephan@cheyenne:~/cvs/libfunutil/lib/cl> l *.pch
-rw-r--r--    1 stephan  users        1908 2003-11-20 12:25 foo.pch


Now i know what i'll be doing tonight!


-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] successful clean checkout/build

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

:)

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] Re: [qub] build tree works, incl install

[Rusty B. <ho...@sb...>]

> That's in CVS now. It's nice to know the config worked as it should have,
> anyway.

:)

Now the configure completes, but the build fails while compiling the
first file (lib/fun/ClassLoader.h); it looks like the compiler isn't
being passed -I../../include.  (Probably because of that, the first
time I tried it, I had a libfunUtil-devel-0.7.999 RPM installed in
/usr from the libfunutil tree, so the build found
/usr/include/fun/ClassLoader.h,  which it didn't like.  Uninstalling
that, rerunning the configure, and running make again caused it to
just fail to find fun/ClassLoader.h.)

--Rusty

[fU] s11nconvert builds if you do this...

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

Until i do a couple file renames in lib/s11n, here's a workaround to build 
s11nconvert.

configure
cd lib
make subdir-{cl,toolbox,s11n}
make SHARED_LIBS
(that must be two separate makes)
export LD_LIBRARY_PATH=$PWD:$PWD/cl
cd ../client/s11nconvert
make
./s11nconvert [-?|--help]

e.g.:
./s11nconvert -f in.s11n -d -v -cldebug -nodedebug

will load + deserialize in.s11n and show a bunch of debug output.

To see something familiar, try:

./s11nconvert -f in.s11n [-of|-ox]


If you want to build without s11n, to avoid this problem altogether, just 
config with --disable-s11n.

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] file-naming booboo...

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

i just realized that i've got a bug:

lib/s11n and lib/funUtil both have a Serializer.h, so include/fun gets out of 
whack. In normal circumstances funUtil will build last, thus overwriting the 
symlink. Then client/s11nconvert will try to use s11n's Serializ{er,able}, 
and will choke.

All this basically means is that s11nconvert won't build at the moment, any 
other client usage of s11n won't work because of the header collision. libFun 
and it's clients should build correctly, however.

i'll fix this soon, but i first have to figure out how best to handle it 
(because i share these subdirs in 3 trees).

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] committed!

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

The s11n-related stuff is in the tree...

It doesn't yet link the library, but it builds all the objects, symlinks/
installs the headers, etc. All of it uses namespace fun, too. :)

Library linking is on the way soon...

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] the rest of the night is mine! all mine!!!

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

Assuming our machines don't go south again, i've got the rest of the night to 
work on Open Source!

Expect the classloader/s11n code in libfun tonight, and i will do what i can 
on the qub tree tonight as well.

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

Re: [fU] decision time

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

On Sunday 16 November 2003 12:53, Rusty Ballinger wrote:
> > Speaking of zaurus: have you got a cross-compiler working?
>
> No, not yet--my problem is that I haven't been able to connect to the
> Zaurus over USB yet, and I'm resisting the temptation to just buy a
> card reader.

LOL!

> > The code i've got isn't compatible at all, but writing a wrapper around
> > it also wouldn't be too difficult, i think.
>
> ?  Maybe I was looking at an old version of the API, but I though
> there were serialize() & deserialize() methods taking a reference to
> a serializer & const deserializer, and you just called get("key",
> value) or put("key", value) on your various member data.  At the time
> the only API difference was that you didn't have to call
> setSerializableClass() in serialize().  (Oh, and the "SERIALIZER"
> macro probably had a different name, or wasn't necessary.)

You're pretty much correct. i renamed de/serialize() to s7e() and d9e(), but 
ONLY for extremely pedantic reasons involving testing the ability to supply 
your own interface. To change the method names a client simply must supply a 
two-method base type and run one macro, then extend his Serializables from 
that base type. There is an example of this at:
  http://s11n.net/s11n/samples.php
near the bottom of the page.

To summarize:

- serializableClass class stuff goes away: that's handled via the INSTANTIATOR 
(aka, SERIALIZABLE_REGISTER) macro and some template voodoo.

- clients can either use the default Serializable implementation or provide 
their own (requires about 15 lines of code). A behind-the-scenes adapter 
class maps the client's API into the core API. e.g., you can call your de/
serialize() methods do_save() and do_load() if you like, as long as their 
const-ness and parameters match the lib's conventions. In fact they can even 
have the same name, and constness figures out which one will be called. (In 
practice doing so is very confusing, however, and does not translate well to 
other languages which don't support const.)

- Serializables from different heirarchies & with different interfaces can 
interact with each other transparently via the s11n API, as the adapter 
classes take care of the API translation.


i haven't yet had a chance to commit this. We've had about 5x normal traffic 
on our web/app servers and they've done nothing by die die die since about 2 
weeks now, and that's kept all of us working 24/7. :(


-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

Re: [fU] decision time

[Rusty B. <ho...@sb...>]

> (Oh, and the "SERIALIZER"
> macro probably had a different name, or wasn't necessary.)

s/SERIALIZER/INSTANTIATOR/, whatever, ha ha ha.

--Rusty

Re: [fU] decision time

[Rusty B. <ho...@sb...>]

> Speaking of zaurus: have you got a cross-compiler working?

No, not yet--my problem is that I haven't been able to connect to the
Zaurus over USB yet, and I'm resisting the temptation to just buy a
card reader.

> > (Since the API is almost
> > line-for-line compatible, it shouldn't be a big deal to switch back &
> > forth.)
>
> The code i've got isn't compatible at all, but writing a wrapper around it
> also wouldn't be too difficult, i think.

?  Maybe I was looking at an old version of the API, but I though
there were serialize() & deserialize() methods taking a reference to
a serializer & const deserializer, and you just called get("key",
value) or put("key", value) on your various member data.  At the time
the only API difference was that you didn't have to call
setSerializableClass() in serialize().  (Oh, and the "SERIALIZER"
macro probably had a different name, or wasn't necessary.)

--Rusty

Re: [fU] decision time

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

On Wednesday 05 November 2003 15:02, stephan beal wrote:
> which needs to be made public before i do: this code is only known to work
> on pretty recent compilers (only tested on gcc 3.3x, and WON'T work on gcc

FYI: i confirmed last night that it works with gcc 3.2 as well - may work with 
3.0 and 3.1, but untested.

After i'm done beating the shit out of our prod servers and get a couple hours 
sleep i'll get this into CVS.

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

Re: [fU] decision time

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

On Wednesday 12 November 2003 15:30, Rusty Ballinger wrote:
> (oops, not sure this went the first time I sent it)

Oops - i forgot that i disabled checking of my wanderinghorse mail account 
because of the spam traffic (200-400/day), and didn't get this til today. :/

> > - gcc 2.x doesn't have the necessary template class specialization
> > support. This features is relied upon /heavily/, and there is no
> > substitute for it.
>
> Hmm.  Well, *not* checking it in doesn't seem real appealing :) so
> check it in, & if I want code which uses serialization to work on my
> Zaurus, I'll use the code from qub.

That sounds fair enough. i've got to do a boatload of work on our production 
servers for the next few hours, then i'll check in what i've got.

Speaking of zaurus: have you got a cross-compiler working? i've got an ipaq 
and the only reason i don't use it is because i haven't gotten 
cross-compiling working. (i'll admit that i gave up early, though.) The ipaq 
and zaurus both run ARMs.


> (Since the API is almost
> line-for-line compatible, it shouldn't be a big deal to switch back &
> forth.)

The code i've got isn't compatible at all, but writing a wrapper around it 
also wouldn't be too difficult, i think.

An important notes about the namespace:

The namespace is set at configure-time, and sed does the translation at 
make-time. This means that foo.cpp becomes ns.foo.cpp and that gets filtered 
to foo.cpp during the build. While this is a bit annoying for maintainance it 
allows me to use the code in different namespaces (currently 3 different 
ones) without any Makefile/code changes. i tried to use macro for this 
purpose but it caused me problems the first time i used the same lib in one 
project, but in different namespaces (there was really a valid reason to do 
so, but the macro approach doesn't support it). Also, the name of the s11n 
lib can be changed via the configure process, so multiple trees can use the 
lib and have their own copies with their own namespaces. (In fact, i share 
the classloader/s11n CVS trees amongst three projects at the moment.)


Before i check it in, i must admit that i've been keeping a secret while i've 
been getting the code ready for prime-time. i haven't been wanting to mention 
it because i have such a bad habit of mentioning long before i ever finish, 
and then never finish. i didn't want to make that mistake this time, so i 
kept my mouth shut. The news is: s11n now has it's own web site:

http://s11n.net

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

Re: [fU] decision time

[Rusty B. <ho...@sb...>]

(oops, not sure this went the first time I sent it)

> - gcc 2.x doesn't have the necessary template class specialization supp=
ort.
> This features is relied upon /heavily/, and there is no substitute for =
it.

Hmm.  Well, *not* checking it in doesn't seem real appealing :) so
check it in, & if I want code which uses serialization to work on my
Zaurus, I'll use the code from qub.  (Since the API is almost
line-for-line compatible, it shouldn't be a big deal to switch back &
forth.)

--Rusty

Re: [fU] decision time

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

On Saturday 08 November 2003 09:52, Rusty Ballinger wrote:
> > i've got about a trillion things to commit to CVS, but there's a bit
> > caveat which needs to be made public before i do: this code is only known
> > to work on pretty recent compilers (only tested on gcc 3.3x, and WON'T
> > work on gcc 2.9x). If that's a big deal let me know and i won't commit
> > it.
>
> "How much" does it not work on 2.9x?  I've been fiddling with

i'm not actually sure. i know of at least two problems:

- gcc 2.95.x does not allow the word 'typename' in some cases where 3.x 
explicitely requires it. (Easy to fix with macros.)

- gcc 2.x doesn't have the necessary template class specialization support. 
This features is relied upon /heavily/, and there is no substitute for it.



-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

Re: [fU] decision time

[Rusty B. <ho...@sb...>]

> i've got about a trillion things to commit to CVS, but there's a bit ca=
veat
> which needs to be made public before i do: this code is only known to w=
ork
> on pretty recent compilers (only tested on gcc 3.3x, and WON'T work on =
gcc
> 2.9x). If that's a big deal let me know and i won't commit it.

"How much" does it not work on 2.9x?  I've been fiddling with
building stuff for my Zaurus, and the ARM cross-compiler is GCC
2.95.2.  (Qt-Embedded is based on Qt-2.3, too.  I don't actually have
anything working on it yet.)

--Rusty

[fU] decision time

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

Yo,

i've got about a trillion things to commit to CVS, but there's a bit caveat 
which needs to be made public before i do: this code is only known to work on 
pretty recent compilers (only tested on gcc 3.3x, and WON'T work on gcc 
2.9x). If that's a big deal let me know and i won't commit it.

-- 
----- st...@ei... - http://www.einsurance.de
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[fU] proposed (minor) tree re-org

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

How does this sound:

Split lib/ up like so:

funUtil/
toolbox/ (name is definately debatable)
s11n/


toolbox =3D=3D really generic stuff: ConfigFile, etc.

funUtil =3D=3D "fun" stuff: Dice, Fudge, etc.

s11n =3D=3D s11n


Dependencies:

toolbox: none
s11n: toolbox
funUtil: s11n


Building libs becomes a bit different, of course. One way would be to gen=
erate=20
the libs directly under lib/, linking to lib/{funUtil,toolbox,...}/*.o. T=
his=20
may not be a good idea, though, as a) object lists have to be duplicated =
in=20
lib/Makefile or b) lib/Makefile needs to use wildcards, which are potenti=
ally=20
dangerous here.

i haven't made any significant changes to s11n in about 5 days, so it's a=
lmost=20
like i have a 1.0 release ready ;). Let me know what you think of the abo=
ve=20
org proposal and i'll base my commits on that. (i've done a lot of renami=
ng,=20
and need to move a lot of stuff around, anyway).


--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org  et al.

[fU] speeding up string-as-properties

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

http://www.cs.princeton.edu/~rs/strings/

sounds very promising, but i think it'll be over my head.

-- 
----- st...@ei... - http://www.einsurance.de
"I feel good!" -- reportedly Yang Liwei's first post-launch words to
Chinese mission control

[fU] doxywizards: doxygen tool to edit config using Qt

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

http://www.stack.nl/~dimitri/doxygen/download.html

it's somewhere on that page. i just found a copy on my new suse 9.0 
distro, and it looks very helpful.


-- 
----- st...@ei... - http://www.einsurance.de
"... NOT because we are America's poodle ..." Tony Blair, 30.9.2003

Re: [fU] woe is me... gcc 3.3.1 breaks it all!!!!

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

i cried too soon... it wasn't too much effort to fix it.
i thought my dreams were about to go bye-bye...

On Tuesday 14 October 2003 22:00, stephan beal wrote:
> i just installed suse 9.0 on my box and the serializable_adapter<>
> trick doesn't compile. If i define a specialziation once it says i've
> done it twice. If i don't do it at all i of course get other errors.
>
> aaaarrrrrgggghhhhh!!!!!

-- 
----- st...@ei... - http://www.einsurance.de
"... NOT because we are America's poodle ..." Tony Blair, 30.9.2003

[fU] woe is me... gcc 3.3.1 breaks it all!!!!

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

i just installed suse 9.0 on my box and the serializable_adapter<> trick 
doesn't compile. If i define a specialziation once it says i've done it 
twice. If i don't do it at all i of course get other errors.

aaaarrrrrgggghhhhh!!!!!

-- 
----- st...@ei... - http://www.einsurance.de
"... NOT because we are America's poodle ..." Tony Blair, 30.9.2003

[fU] silly classloader tricks, part 1: selecting a Serializer

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

Using ClassLoader<> to assign keys to Serializers:


        enum OutModes { NoFormat =3D 0x0000,
                        TextFormat =3D 0x0001,
                        XMLFormat =3D 0x0002,
                        SimpleXMLFormat =3D 0x0004,
                        ParenFormat =3D 0x0010,
                        HexFormat =3D 0x0020,
                        CompactFormat =3D 0x0040
        };

        typedef ClassLoader<basic_serializer,int> S8rLoader;

        S8rLoader::register_subtype<FunXMLSerializer>( XMLFormat );
        S8rLoader::register_subtype<SimpleXMLSerializer>( SimpleXMLFormat=
 );
        S8rLoader::register_subtype<FunTxtSerializer>( TextFormat );
        S8rLoader::register_subtype<ParenSerializer>( ParenFormat );
        S8rLoader::register_subtype<HexSerializer>( HexFormat );
        S8rLoader::register_subtype<CompactSerializer>( CompactFormat );


        int outmode =3D NoFormat;

        // get selected output mode:
=09if( args.get_bool( "ox", false ) ) outmode +=3D XMLFormat;
        else if( args.get_bool( "op", false ) ) outmode +=3D ParenFormat;
        else if( args.get_bool( "osx", false ) ) outmode +=3D SimpleXMLFo=
rmat;
        else if( args.get_bool( "ot", false ) ) outmode +=3D TextFormat;
        else if( args.get_bool( "oh", false ) ) outmode +=3D HexFormat;
        else if( args.get_bool( "oc", false ) ) outmode +=3D CompactForma=
t;

        basic_serializer * serializer =3D 0;
        serializer =3D S8rLoader::load_class( outmode );
        // may be NULL, of course

Thus, it makes a convenient map of arbitrary key types to object factorie=
s.=20
This is exactly how i map file formats' magic cookies to input parsers.

--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org  et al.

[fU] a more generic, in-language solution for "the class name problem"

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

This should work for just about any project. i'll admit it bloats the glo=
bal=20
space a bit (one extra helper class per registered class), but it's very=20
generic and easy to use...


namespace { // anon ns important for linking
        /**
           A slimmer, more general-purposes class than
           classloader_registerer<>.
           It MUST be specialized to work.
        */
        template <class T> struct class_name
        {=20
                class_name(){}
                ~class_name(){}
                operator const char * () const
                {=20
                        assert( 0 /* this class_name<> is unspecialized! =
*/ );
                        return "error::class_name<unspecialized>";
// a more sane default would be typeid(T).name()
                }
                // static const char * classname =3D 0;
                // ^^^^^ we can't initalized a non-integral type this way=
 :(
                static const char * name()
                {
                        assert( 0 /* this class_name<> is unspecialized! =
*/ );
                        return "error::class_name<unspecialized>";
                }
        };
}

// call this from outside a namespace to register a class_name<Type>
#define CLASS_NAME(Type) \
=09namespace {\
        template <> struct class_name<Type> {\
                class_name(){}; ~class_name(){}; \
=09        static const char * name() {return # Type; }\
                operator const char * () const { return this->name(); }\
        };}



Usage:

CLASS_NAME(MyClass);

COUT << "name =3D " << class_name<MyClass>() << std::endl;
COUT << "name =3D " << class_name<MyClass>::name() << std::endl;


Caveat:

typedef std::vector<int> FooType;
CLASS_NAME(FooType); // will use "FooType" :(

Maybe that's useful in some contexts, but i'm not sure if it's a feature =
or a=20
bug. It's not name-collision-proof, but it is the type passed to=20
class_name<T> which is important, anyway.


This would be more efficient to implement as global funcs, but func templ=
ates=20
can't be specialized, AFAIR.

--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org  et al.

[fU] documentation caveat regarding classloading:

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

One of the most important classes, classloader_register<> does not get 
documented by doxygen because it is an anonymous namespace (for linking 
reasons). It is in toolbox/ClassLoader.h, and explains how the 
collisions-free class/factory registration is handled. i wish i knew 
how to get doxygen to doc it :/.

Here's what the INSTANTIATOR-like macro looks like:

#define CLASSLOADER_REGISTER(BaseT,SubT) \
        namespace { template<> struct 
classloader_registerer<BaseT,SubT>{\
                typedef BaseT base_t; \
                typedef SubT sub_t; \
                typedef classloader_registerer<base_t,sub_t> this_t; \
                static int placeholder; \
                static std::string class_name(){ return # SubT; } \
                static int startup( const std::string & classname) { \
                        return toolbox::ClassLoader< base_t 
>::register_factory( classname, toolbox::Factory< base_t, sub_t 
>::newInstance ); \
                }\
        }; \
        int classloader_registerer<BaseT,SubT>::placeholder = 
classloader_registerer<BaseT,SubT>::startup( # SubT );\
        }

// string arg to startup(...) is not strictly necessary any more.

that ensures that when the app starts up (or DLL is dlopen()ed) that the 
proper classloader is registered for the given type. The BaseT 
parameter is the one used by clients when "casting". e.g., that would 
be LoadableClass or Serializable in the current libfun code. The SubT 
param is, of course, a subtype of BaseT. The docs/headers cover this in 
excruciating detail (or should, anwyay).

The classloader is fundamentally different than conventional ones. It 
doesn't read ANY symbols from DLLs. Instead it just opens them, 
triggering these "callbacks", and then asks itself if someone 
registered the appropriate factory.

-- 
----- st...@ei... - http://www.einsurance.de
"... NOT because we are America's poodle ..." Tony Blair, 30.9.2003