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
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
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.)
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk