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: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-05-04 15:07:37

Robert Ramey wrote:
> 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.

Yes, ..._KEY in the header and _IMPLEMENT in the cpp. By the way, it 
appears that BOOST_CLASS_EXPORT_KEY requires #include 
<boost/serialization/extended_type_info.hpp> for my headers to compile 
in the absence of any archive header. Is that intended?

> 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.

Yes I've done 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.

Hmm, seems like I asked about two mutually exclusive ways. ;-)

> 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.

Thant's what I've been thinking. It's not so bad if I can then get rid 
of the BOOST_CLASS_EXPORT_XXX macros. Also I was expecting 
archive::register_type to merely need a class forward declaration, but 
appears that it requires a complete type. Is that intended? That adds a 
lot of coupling.

> 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.

Sigh, we're trying to minimize our dll/dylib usage.

Thanks, Jeff