Boost logo

Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2005-01-13 18:13:00


Mithun R K wrote:

>...However, my question had more to do with separate
>instantiations of Singleton<MyClass> in different shared libraries. Since
>each lib has a separate Singleton<MyClass> definition, won't each lib also
>have its own singleton-instance? I'm pretty sure the loader won't be
>stripping out multiple instantiations across shared libraries (well, not on
>HPUX, anyway). Won't this pose a problem?
>
>
Hum. I honestly don't know. Whats interesting is that this may be
another reason that the CRTP model is better. The final singleton class
used by client code would (probably) not be a templated class (it would
just derive from one), and would (most likely) have its implementation
compiled into its own discrete unit.

><quote>
>Perhaps the lifetime of the dlls themselves could be managed with
>singletons? When the dll's dtor is called, it could unregister the relevant
>classes and unload the dll.
></quote>
>
>The loading/unloading of the dll's isn't really in our control, is it? It's
>the dynamic-library-loader of the OS that does it. (/usr/lib/libdld.so, on
>HPUX). This problem is bound to happen on any app with multiple dlls, right?
>I've to use a hack on HPUX fix this... I'm open to ideas.
>
>
Sorry for my naivety, I haven't really done a lot of work involving
multiple dlls in C++. My primary experience with such scenarios has
been with C# in .NET, where one has the option of using the classes in
the System.Reflection namespace to load other assemblies on command.

>Thank you for looking at my approach... I really appreciate it.
>
>Ok, so I shouldn't be introducing a virtual-base for the singletons... If I
>were to register only Destroy functors with the SingletonRegistry (each
>knowing how to destroy its Singleton), would that do? That would move the
>virtual-base out of the Singleton, and into the "SingletonDestroyer" (I'll
>still need a virtual base, because the SingletonRegistry will need to hold
>all the Destroyer functors).
>
>
Actually, you don't need a virtual base... because of the very nature of
a singleton (single instance) you can use plain old static functions.
Those functions would then be responsible for tracking down and
destroying the single instance.

-Jason


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk