Re: [Boost-users] [serialization] export.hpp changes from 1.37 to 1.38

Subject: Re: [Boost-users] [serialization] export.hpp changes from 1.37 to 1.38
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-02-16 23:34:07

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.

...

Looking at it, I don't see any reason why couldn't replace the

namespace boost {
namespace archive {
namespace detail {

with just

namespace {

Would that address your problem? Would it create any other problems?

Robert Ramey

I don't remember why this was done.  I don't know if there was
even a specific reason.

>>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).
>>
>>
>
>
>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users