[boost] [serialization] BOOST_CLASS_EXPORT and module boundaries

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-01-21 12:45:13

Vladimir Prus wrote:

>Looks like BOOST_CLASS_EXPORT does not work across library boundaries, or I 
>misunderstand how it should work.

>My understanding was that as you declare derived class, you also invoke 
>BOOST_CLASS_EXPORT on it, and now you can save pointers to that class 
>everywhere.

>But this does not work in my tests. Unless I use BOOST_CLASS_EXPORT in the 
>code which does actual saving, I get:

>/space/NM/boost-serialization/boost/serialization/oserializer.hpp:297: static 
>void boost::serialization::detail::save_pointer_type<Archive, 
>TPtr>::polymorphic<T>::save(Archive&, const T&, const 
>boost::serialization::basic_oserializer*) [with T = B, Archive = 
>boost::archive::text_oarchive, TPtr = B*]: Assertion `__null != vp' failed.

>Test case attached. Am I doing something wrong?

This is explained in the header code at basic_archive.hpp:125
Remember your problem with PIMPL ?  well it shows up again with export in a particularly
subtle way.  Suppose I export a derived pointer but otherwise never explicitly refer to
it a compile time.  Code with template parameters <Archive, T> will never get instantiated.
So EXPORT has two functions
a) make sure that a class is registered in a archive by its key string
b) instantiate required code to serialize the given type with all the archives used by the program.

In order to do this, EXPORT builds an mpl::list  of all the file types used by the module by
check for definition of the head inclusion guards.  Using mpl, the proper serialization code
is explicitly instantiated so that it can be invoked if necessary. 

In order for this work, export.hpp has to come after the archive header .hpp files.  This
is enforced by the code that tripped above.

I spent lots of time finding a solution to this difficult problem and am pleased with the result.

However,  I'm still slightly unclear as to what I should recommend for the order of headers.
Inclusion guards make it a non-issue from a practical stand point.  However I I took
pains to make serialization independed of archive not vice versa so my preference
would be that serialization headers go before archive headers, but this breaks my
implementation of export.

I'll add some explanation about this to the manual section in question.

Robert Ramey