On Tue, Feb 17, 2009 at 9:27 AM, Robert Ramey <ramey@rrsd.com> 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