On Mon, Jul 25, 2011 at 6:30 PM, Robert Ramey <ramey@rrsd.com> wrote:
Look at the most recent documentation. BOOST_CLASS_EXPORT is now replaced with two different macros (BOOST_CLASS_EXPORT_DECLARE and DEFINE or something like that) This permits one to arrange his code so that multiple definitions are avoided.
Thank you very much for your answer. I tried using the two new macros (BOOST_CLASS_EXPORT_KEY and BOOST_CLASS_EXPORT_IMPLEMENT). I replaced all the previous BOOST_CLASS_EXPORT in SerClassExport.h with the corresponding _KEY, and this solved the linker problem. So far, so good. Then, in order to provided explicit code instantiation, I created a new translation unit, "SerClassExport.cpp", as follows: ///////////////////////////////////////////////// // SerClassExport.cpp #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include "Model_Root.h" #include "SM/SM_Node.h" [...Many other class definition headers includes] [...] #include <boost/serialization/export.hpp> BOOST_CLASS_EXPORT_IMPLEMENT(model::Root) BOOST_CLASS_EXPORT_IMPLEMENT(sm::Node) [...Many other class export definitions] [...] ///////////////////////////////////////////////// I did it this way because, as far as I understand, I must include all the archives before the _IMPLEMENT macros. Now, when compiling SerClassExport.cpp, the compiler again goes out of heap space, as it did before splitting the original unique .cpp into two translation units - one for each archive type. Am I doing it right? It seems that I did not catch how to have two separate translation units without redefinition of guid_initializer::g. Of course, if I remove the "extra_detail" namespace in export.hpp (coming back to an unnamed namespace as it was in 1.44.0), everything goes ok, but I can hardly think that this might be a feasible solution. Any idea on possible alternatives? Thank you in advance, Enrico