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: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-17 01:44:11

Unnamed namespace in a header... Ugh!

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Feb 16, 2009 at 8:34 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 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
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users