Jeff Flinn wrote:
I've followed the doc's 'Static Libraries and Serialization' approach. To move the serialize implementation from the header to the cpp file for my classes in my hierarchy which are serialized through base class pointer. Which runs on MSVC8, after linking with /OPT:NOREF.
Unfortunately the BOOST_CLASS_EXPORTxxx facilities appear to be optimized away on gcc/xcode, even though all of the 'strip' settings are off. What approach are others taking to resolve this?
Hmmm I'm assuming BOOST_CLASS_EXPORTxxx refers to BOOST_CLASS_EXPORT_KEY and the other one. This is my latest refinement to resolve the issues related to DLLS. It would seem to me the same and/or similar treatment would also apply to static libraries. Note that in a static library you'll have to explicitly instantiate the serialization functions for the archive classes you use. I'll presume you're past this.
Robert's reply to Emil Dotchevski on Sep 25, 2008 suggests that explicitly calling ar.register(static_cast
(0)); is the only portable way to ensure registration, is this still the case?
It is still the case and I see no change in the future. EXPORT depends upon non-portable facilities which it seems all our compilers implement (albeit with different syntaxes !! Maybe the C++ standard commitees might want to look in to issues related to dynamic linking?)
Should explicit registration be done in combination with or en lieu of BOOST_CLASS_EXPORTxxx?
That would be one way. Another way would be to create a "pseudo module" in your program which explicitly refers to the serialization functions. (for example by taking their address?) You're kind of on your own. Note that the current tests for the serialization library on both VC and gcc include tests of DLLS where the implemention is in a DLL. One way would be to use a DLL /shared library rather than a static library. The compiler can't discard the code in these cases. Robert Ramey