
Peter Dimov wrote:
Dan Thill:
And, according to the trunk version, putting serialization code in DLLs is supposed to work--using the same organization I'm trying to use now. But it looks like it won't work with static libs.
The easiest way to force the inclusion of a particular .o(bj) file is to call a function from it. You could call a function from each .cpp file in which you have an export macro.
This is in fact not much different than just having "register<X>()" calls instead of export macros, which is why I tend to prefer this low-tech approach instead of relying on implicit registration via static object constructors.
Maybe the serialization library could provide an alternative function-based registration mechanism that would be immune to the static library problem. Or maybe it already provides it:
guid_initializer< T >().export_guid( "T" );
This is less convenient, but has the advantage of working. :-)
I believe that making a *.cpp file with the macros BOOST_CLASS_EXPORT(T) would be exactly equivalent to the above. Robert Ramey