Re: [boost] [serialization] export.hpp changes from 1.37 to 1.38

Subject: Re: [boost] [serialization] export.hpp changes from 1.37 to 1.38
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-02-13 23:42:37

The documentation in 1.38 clarifies what seems to be the best way
to use BOOST_CLASS_EXPORT.  This is to use the macro inside
the *.cpp file so it doesn't get instantiated multiple times.   So you might

create a file t.hpp

struct T {
    template<typename Archive>
    void serialize(Archive & ar, const unsigned version){
    {}
};

t.cpp which looks like the following:

#include <boost/archive/text_oarchive.hpp>

#include <boost/archive/text_iarchive.hpp>

#include <boost/archive/binary_oarchive.hpp>

#include <boost/archive/binary_iarchive.hpp>

#include "SerializeT.hpp"
#include <boost/serialization/export.hpp>
BOOST_CLASS_EXPORT(T)

I think that'll do it.

It amounts to "pre-registering" all derived types at compile time
as oppose to "pre-registering" all derived types at run time with 
ar.register_type.

Take you choice.

Robert Ramey

Chard wrote:
>> The BOOST_CLASS_EXPORT.. macros have been moved into a detail
>> namespace (1.38) from a (public) anonymous namespace (1.37).
>>
>> I'm guessing that the reasoning for this was in order to avoid many
>> definitions of the class singletons.  However, this appears to have
>> enforced that all of the guids (for all archive types) now have to
>> reside in a single compilation unit.
>>
>> The attached code illustrates the limitation; this compiles under
>> 1.37 but results in duplicate symbol definitions in 1.38 (with
>> MSVC7.1).  It worked with 1.37 because the anonymous namespace
>> ensured no symbol clashes, but now the symbols are all in the same
>> namespace.
>>
>> The example shows a case where two archive types (xml and binary)
>> might be
>> in use.  The obvious solution to this (simple) case would be to just
>> use a single compilation unit, which brings in the guids for both
>> binary and xml. However, turning a blind eye to the 'untidiness',
>> this fix does not help
>> with the project we're working on.
>>
>> In our project, there is not just a simple type being serialized;
>> there are
>> a lot more classes and a bit of mpl thrown in.  This actually
>> resulted in breaching the COFF symbol limit (approx. 65k) with
>> MSVC7.1, so we were
>> forced to split the serialization.  In fact, we had to split both
>> the save and load parts of the binary serialization.
>>
>> Our current workaround is to use the archive.register_type<...>
>> method, and ignore the export macros, but this does mean ensuring
>> all types are covered (as described in the documentation).
>>
>>
>
>
>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost