a template-based, DLL-capable classloader

stephan beal

Good afternoon, C++ers,

(i hope this is not viewed as an advertisement or shameless plug, and i
appologize if it is interpretted that way.)

i have developed a template-based classloader which is capable of loading
from DLLs (on Linux-ish systems, as i have little experience with other
platforms, but the platform-specific code is limited to about 4 lines). i
mention this not the world needs another classloader, but because i think
the model and implementation might be interesting for class template fans,
primarily for it's two main features:

- compile-time type safety even for classes loaded via DLLs (i know nobody's
gonna believe me on that ;).

- NO casts are necessary, neither client-side nor in the core library.

(Well, okay, and admittedly because it would tickle me pink if someone more
well-versed in class templates than i would have a look at them. ;)

The code is not structurally suitable for pasting into a usenet post, but
the source tree is avaiable here:

http://s11n.net/class_loader/

Caveat: it's only known to build with gcc 3.3x, and known to NOT work with
gcc 2.x. YMMV with other compilers.

(PS: how the no-casts-necessary-type-safety for DLLs is achieved is
explained in the library manual, availabe in PDF/PS/HTML formats at the
above link.)

Take care,

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

Jul 19 '05 #1

tom_usenet

On Tue, 28 Oct 2003 14:00:46 +0100, stephan beal
<stephan@wanderinghorse.net> wrote:
[color=blue]
>Good afternoon, C++ers,
>
>(i hope this is not viewed as an advertisement or shameless plug, and i
>appologize if it is interpretted that way.)
>
>i have developed a template-based classloader which is capable of loading
>from DLLs (on Linux-ish systems, as i have little experience with other
>platforms, but the platform-specific code is limited to about 4 lines). i
>mention this not the world needs another classloader, but because i think
>the model and implementation might be interesting for class template fans,
>primarily for it's two main features:
>
>- compile-time type safety even for classes loaded via DLLs (i know nobody's
>gonna believe me on that ;).
>
>- NO casts are necessary, neither client-side nor in the core library.
>
>(Well, okay, and admittedly because it would tickle me pink if someone more
>well-versed in class templates than i would have a look at them. ;)
>
>The code is not structurally suitable for pasting into a usenet post, but
>the source tree is avaiable here:
>
>http://s11n.net/class_loader/
>
>Caveat: it's only known to build with gcc 3.3x, and known to NOT work with
>gcc 2.x. YMMV with other compilers.
>
>(PS: how the no-casts-necessary-type-safety for DLLs is achieved is
>explained in the library manual, availabe in PDF/PS/HTML formats at the
>above link.)[/color]

A quick comment

static int register_factory( const KeyType & key, factory_type factory
= 0 );

could be (to avoid an implementation detail being in the interface):
static void register_factory( const KeyType & key, factory_type
factory = 0);

by using the comma operator at the registration site:

namespace
{
int global = (factory::register_factory(key), 0);
}

It looks nicely documented, but I haven't got a unix system to try it
out on...

Tom

Jul 19 '05 #2

stephan beal

tom_usenet wrote:[color=blue]
> A quick comment
>
> static int register_factory( const KeyType & key, factory_type factory
> = 0 );
>
> could be (to avoid an implementation detail being in the interface):
> static void register_factory( const KeyType & key, factory_type
> factory = 0);
>
> by using the comma operator at the registration site:
>
> namespace
> {
> int global = (factory::register_factory(key), 0);
> }[/color]

Oh, weird! :)
That's an excellent solution to the problem. i have considered using the int
in cases where a class_registerer<> fails (e.g., in client-supplied
registerers, should someone really feel the need to write one). i'm glad to
now have a way around needing it, though.
[color=blue]
> It looks nicely documented,[/color]

Thank you :). i've spent a lot of time on the docs.
[color=blue]
> but I haven't got a unix system to try it
> out on...[/color]

And i haven't got a Windows box to port it to ;). Apparently Cygwin
installations are missing libdl, and i don't know an alternative to using
libdl with dlopen() ("don't know" as in "haven't been doing this very
long", as opposed to "there isn't one").

Thanks for your comments!

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

Jul 19 '05 #3

Roger Leigh

On 2003-10-28, stephan beal <stephan@wanderinghorse.net> wrote:[color=blue]
> tom_usenet wrote:[color=green]
>> but I haven't got a unix system to try it
>> out on...[/color]
>
> And i haven't got a Windows box to port it to ;). Apparently Cygwin
> installations are missing libdl, and i don't know an alternative to using
> libdl with dlopen() ("don't know" as in "haven't been doing this very
> long", as opposed to "there isn't one").[/color]

There's GNU libltdl, part of GNU libtool, which is a
platform-independent libdl abstraction. It wraps LoadLibrary() on
Windows, for example. It probably wouldn't take much effort to use
libltdl, since you just need to change dlopen() to lt_dlopen() etc.. In
the Gimp-Print project (written in C), I allow both to be used, selected
at configure time and just a few #ifdefs to use one or the other.

If you're interested, I can give you pointers to the configure checks
and the module loader code.


--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.

Jul 19 '05 #4

stephan beal

tom_usenet wrote:[color=blue]
> A quick comment
>
> static int register_factory( const KeyType & key, factory_type factory
> = 0 );
>
> could be (to avoid an implementation detail being in the interface):
> static void register_factory( const KeyType & key, factory_type
> factory = 0);[/color]

Just follow up:

Tom, i implemented this last night and it works like a charm. i'm making a
new release today with your name in the credit.

(The hard part was removing all of the documentation which explained the
reason for the bogus int return value! ;)

Thanks again,

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

Jul 19 '05 #5

stephan beal

Roger Leigh wrote:[color=blue]
> There's GNU libltdl, part of GNU libtool, which is a
> platform-independent libdl abstraction. It wraps LoadLibrary() on
> Windows, for example. It probably wouldn't take much effort to use
> libltdl, since you just need to change dlopen() to lt_dlopen() etc.. In
> the Gimp-Print project (written in C), I allow both to be used, selected
> at configure time and just a few #ifdefs to use one or the other.
>
> If you're interested, I can give you pointers to the configure checks
> and the module loader code.[/color]

(tried off-list, but it bounced)

Hi, Roger! Yes, any pointers would be wonderful! This is my first time using
dlopen(), so i'm not at all aware what the various alternatives are. A week
or two ago i found libltdl on a Cygwin box (while looking for libdl), but
couldn't figure out if it was related to what i needed or not. :/

Thanks very much in advance,

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

Jul 19 '05 #6