RIVASSEAU Jean Noel wrote:

Hello,

CommonSerialize.h - remove the following

#include #include

and add the following:

#include

test_independent.cc - change the top to look like the following:

// INDEPENDENT TEST

#include #include

#include #include #include #include #include <fstream>

This won't work. Since you now have the archive headers in only one place, there is no multiple definition problem. However serialization code is *not* instantiated for MObject or MemberVariableSpecification. This is normal since when compiling the .cc that contains this code, there is no archive header included and so the export.hpp has no effect. The code is here but is not instantiated.

So in order to follow this advice:

a) include all boost/serialization/.. headers in each class file. b) include NO boost/archive/... headers in any class file c) make a "template instantiation module" which instanticiates code for all archives I plan to use. This can be either in the app or in a library. d) lihk and execute without problem.

I have to explicitly instantiate the serialization code for the needed archive in the .cc files. That is, do:

template void saveboost::archive::xml_oarchive( boost::archive::text_oarchive & ar, const MObject & m, const unsigned int file_version );

And same for load. This is what you do in demo_pimpl.cpp. Is that what you usually do and recommend to do?

In a smaller program - example the tests. One can include the serialization headers which might contain BOOST_EXPORT after any archives used. This will guarentee that needed code is instantiated. In larger programs, I use the method illustrated in demo_pimpl to explicitly instantiate code for archives that are used. On a larger project, I would make an instantiation module which will instantiate code for all the archives I might ever use. Alternatively, I might use the polymorphic archive. In this last case I do the following to avoid "code bloat". a) I build a separate library of class modules. b) I instantiate all code that might be used c) I use compile time switches to make linking occur at the function level rather than the module level. d) I link my "real project" against this class library.

This has the advantage to avoid big compilations (these code instantiations will only occur when the class to serialize has indeed changed).

Indeed - and this is a big advantage for xml_archives which take quite a bit of time to compile.

However this has the inconvenience of manually instantiating every template (and if you want to change your archive format , eg from text to xml for example, everything needs to be changed).

This is true. But this is a minor in my opinion. The root cause of this situation is that linkers complain about multiply defined functions - even when those functions are identical. Maybe someday we'll have smarter linkers - but until then this works quite well. It does require that one spend a little time explicitly considering code instantiation. But this isn't necessarily bad. Letting the compile/linker do all the work will lead to code bloat and compilation time problems. Robert Ramey