[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).
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
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@rrsd.com> wrote in message news:gn5i1k$kcm$1@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
Chard wrote:
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.
That is a surprise to me. it would seem that we're trying to address two issues at the same time. One creating of an extended type info record and the other instantiating per archive code. We'look into it. Robert Ramey
participants (2)
-
Chard -
Robert Ramey