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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users