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: Chard (boost_at_[hidden])
Date: 2009-02-14 04:53:53

This is pretty much what we had originally, but, like I said, we could not
compile it because of the number of symbols generated.  This probably
highlights limits with MSVC7.1 because I believe the COFF limit has been
increased in later versions, but (for the moment) it does mean we only have
one choice: register_type<>.

The file-splitting workaround, which was okay with 1.37:

File1.cpp
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
#include "t.hpp"
#include <boost/serialization/export.hpp>
BOOST_CLASS_EXPORT(T)

File2.cpp
#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include "t.hpp"
#include <boost/serialization/export.hpp>
BOOST_CLASS_EXPORT(T)

is no good for 1.38.  It would be nice if this archive separation were 
possible.

Or, alternatively, if a class was registed with one type of archive then it 
would work with any (so the second macro usage could be removed).

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:gn5i1k$kcm$1_at_ger.gmane.org...
> 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
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>