Re: [Boost-users] Serialization : unregistered_cast & otherquestions

From: Hugh Hoover (hugh_at_[hidden])
Date: 2006-02-27 13:34:48

On Feb 27, 2006, at 08:51, Robert Ramey wrote:
> *** Hmmm - I'll look into this.  I would have expected that  
> additional code
> would be generated if and only if <boost/archive/...
> headers are included.  If these are included only once, I wouldn't  
> expect
> any multiple definitions. The top of export.hpp
> includes the following:
>
> // if no archive headers have been included this is a no op
> // this is to permit BOOST_EXPORT etc to be included in a
> // file declaration header
> #if ! defined(BOOST_ARCHIVE_BASIC_ARCHIVE_HPP)
> #define BOOST_CLASS_EXPORT_GUID_ARCHIVE_LIST(T, K, ASEQ)
>
> which I would expect would make a BOOST_EXPORT an effective no-op  
> if no
> archive files are included.

I'll chime in, as I'm having exactly the same issue, but on darwin/ 
gcc-4 with code in multiple dynamically loaded libraries... (I have  
other issues too, I get to those later)

The problem is that although export.hpp is only included once per  
generated .o file, there are multiple .o files all including the same  
headers - and each therefore generates the same template  
instantiations, thereby causing the multiple definitions during  
linking.  Also - the same headers may be included in multiple shared  
libraries, exacerbating the problem with the same code instantiated  
into multiple libraries - a serious problem if there are singletons.

I may not be understanding this correctly - here's what >I< think  
needs to happen - please correct me.

For any derived class, there is a set of code (templates) that need  
to be instantiated for each archive type (specifically, the list  
boost::archive::detail::known_archive_types::type, for the templates  
guid_initializer<T> and export_instantiate<T, archive_list>)
 From what I see, these are NOT declarations required by the other  
serialization code, but singletons that, during construction,  
register the serializers to the derived classes with the  
extended_type_info class registry.  Is that incorrect?

If the above is correct, then the BOOST_EXPORT_CLASS should only be  
in exactly one implementation file (.cpp, .C, .cc, whatever).  And  
also, THAT implementation file should ONLY be linked into one shared  
library.