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 16:38:58

Robert Ramey wrote:
> Jeff Flinn wrote:
>>>> 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.
> 
> The basic problem is:
> 
> application pulls from the static library only those functions explicitly
> referred to.
> 
> call a function through a base class pointer does explicitly refer
> to the derived class.
> 
> Of course these two ideas conflict and there can be no resolution
> without violating the original motivation for these concepts in the first
> place.  Another way of saying this is that we want to couple our
> application to some type/function which we haven't explicitly referenced.
> 
> The only way to resolve this is to explicitly reference these 
> types/functions.
> The register_type facility does this on an archive by archive level.
> EXPORT does this for the whole program so it propagates this facility
> to the all archives.
> 
> So the simplest would be to use register type.  It might be possible
> to enhance EXPORT in some way for static libraries.  The problem
> is that it would start sucking in all the library code whether need
> or not - thereby defeating the whole purpose of a static library
> in the first place.
> 
> Maybe a nice way would be to craft something like
> 
> #include <boost/serialization/extended_type_info_typeid.hpp>
> 
> using boost::serialization;
> 
> void
> register_all_modules(){
>     const extended_type_info & eti = 
> extended_type_info_typeid<my_type>::get_const_instance    const 
> extended_type_info & eti = 
> extended_type_info_typeid<my_type>::get_const_instance();

I'll have to study what you've presented here.

Just as another data point, on MSVC I was able to link with /OPT:REF to 
optimize away unref'd functions and data by declaring my serialize 
methods as:

     template<class Archive>
     BOOST_DLLEXPORT void serialize(Archive&, const unsigned int)
     BOOST_USED;

(the macros being defined in your force_include.hpp) and all links and 
runs perfectly, reducing my release exe size from 3.6MB to 2.6MB. I'm 
guessing you have a #pragma somewhere that is responsible for generating 
.exp and .lib files for my executable as I have no explicit MSVC 
settings to generate these.

Jeff