Boost logo

Boost :

Subject: Re: [boost] [Serialization] BOOST_CLASS_EXPORT regression on SunCC
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-17 13:41:59


On Tue, Feb 17, 2009 at 9:27 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> Note there is one important scenario for which EXPORT is
> by far the best solution. That is for plug-ins in DLLS. In this
> scenario, each DLL automagically registers the types it uses
> when it is loaded, and unregisters those same types when it
> is unloaded. This means that one can make a main program
> which will handle all future types even though they are not currently
> known.

Dynamic libraries have initialization and termination routines, there
is no problem to do the registering/unregistering there. The main
program still doesn't need to know about the derived classes being
registered and this does not require BOOST_CLASS_EXPORT.

The benefit of BOOST_CLASS_EXPORT is that it allows the dynamic
library itself not to know about the derived classes it registers.

> As far as I know, runtime linking and its implications
> for code compilation are not addressed by the C++ standard
> and this is why we have those compiler specific hacks in there.

That's only half of the story. As an automagic registration of types,
BOOST_CLASS_EXPORT isn't guaranteed to work even if you don't use
dynamic linking.

The problem is that the C++ standard allows the compiler to deadstrip
the namespace-scope objects whose constructors are supposed to
register the types, unless code from that module is explicitly called
(which is roughly equivalent to a requirement that the program "knows
about" the types being registered.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


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