Re: [Boost-users] [serialization][1.42.0] gcc(4.01)/xcode(3.1.2) failure to register type

Subject: Re: [Boost-users] [serialization][1.42.0] gcc(4.01)/xcode(3.1.2) failure to register type
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-05-04 15:39:24

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<myType *>(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