[serialization] export.hpp changes from 1.37 to 1.38
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).
Oops, ignore this here, reposted to the dev group, where it was intended..
"Chard"
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).
--------------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Fri, Feb 13, 2009 at 3:55 PM, Chard
The BOOST_CLASS_EXPORT.. macros have been moved into a detail namespace (1.38) from a (public) anonymous namespace (1.37). <snip> 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).
This is the better approach IMO anyway because in some typical uses of the automatic registration the C++ standard allows the compiler to deadstrip it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
AMDG Robert Ramey wrote:
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?
It would be better to use namespace boost { namespace archive { namespace detail { namespace { to avoid putting init_guid in the global namespace. In Christ, Steven Watanabe
Looks like this has become the active thread, despite my posting mistake/repost. Oh well..
Robert Ramey wrote:
Would that address your problem? Would it create any other problems?
Yes, it would address my problem because that would be as it was pre-1.38. However, there must have been some argument for making the change.
I don't remember why this was done. I don't know if there was even a specific reason
Did you not make the change, then? 1.37 wasn't that long ago ;-). Any SVN comments? I know there have been several (non-library specific) discussions regarding putting anonymous namespaces in headers, and, generally, how it is a bad thing due to each compilation unit instantiating a different linker name for the same object (violating ODR?). Is this a case that warrants it? I guess it uses a little bit more memory, but is that the only issue? Chard.
Chard wrote:
Looks like this has become the active thread, despite my posting mistake/repost. Oh well..
Robert Ramey wrote:
Would that address your problem? Would it create any other problems?
Yes, it would address my problem because that would be as it was pre-1.38. However, there must have been some argument for making the change.
I don't remember why this was done. I don't know if there was even a specific reason
Did you not make the change, then? 1.37 wasn't that long ago ;-). Any SVN comments?
It was done in conjunction with another change. I suspect it was an application of a "rule" don't put anonomous namespaces in headers.
I know there have been several (non-library specific) discussions regarding putting anonymous namespaces in headers, and, generally, how it is a bad thing due to each compilation unit instantiating a different linker name for the same object (violating ODR?).
Is this a case that warrants it? I guess it uses a little bit more memory, but is that the only issue?
I would like to change it back. but before I do, I would like to hear other opinions. Robert Ramey
AMDG Robert Ramey wrote:
I would like to change it back. but before I do, I would like to hear other opinions.
Adding an anonymous namespace should not cause any code that works now to break. In Christ, Steven Watanabe
It turns out that we can't get away with the register_type<> workaround, at
least if we want to support anything we've serialized with earlier versions.
The register_type<> approach produces incompatible archives to those
produced with BOOST_CLASS_EXPORT.
This all comes about because the class type is registered in the archive the
first time it is seen. For the register_type<> case, it is marked as 'seen'
immediately, so it is never written to the archive..
IMO I don't believe the choice of how the class is registered should affect
the archive contents, but addressing this issue could be tricky at this
stage - to ensure it is backwards compatible, for sure. The archive would
have to be examined to see if the class were there or not.
If it's too much to address this issue, then, at least, the documentation
should be updated to make it clear that once the choice is made...that's it.
Anyway, FWIW, here's the test code to demonstrate:
#include
AMDG
Robert Ramey wrote:
I would like to change it back. but before I do, I would like to hear other opinions.
Adding an anonymous namespace should not cause any code that works now to break.
In Christ, Steven Watanabe
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
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (4)
-
Chard -
Emil Dotchevski -
Robert Ramey -
Steven Watanabe