Guy Premont wrote:
Hi,
I've done research on the list and could not find any pointer about my problem so here it is.
I'm using windows, boost 1.40, and vc9, i am not using polymorphic archives, and i'm using member function serialization.
In a big project, separated in different modules, I want to spread serialization also into different DLLs. Typically, i have a base class Base, implemented in Base.dll and the serialization is in BasePersistence.dll. The serialization member functions are marked with ddlexport or dllimport, explicit template instantiation is done to force inclusion in the dll. So far everything is working.
Now I have a class Derived, derived from Base, implemented in Derived.dll. If i have only one serialization library that handle all classes, it works fine, but I want the serialization to be split with the same module as the implemention. So, I want the serialization of class Derived to be in DerivedPersistence.dll. It compiles but fails to link, There are a lot of undefined symbols, most are in boost::serialization::archive namespace.
Is there a special BOOST_DLL flag to use? It seems like the DerivedPersistence.dll does not find in BasePersistence.dll the functions it should find.
Is it at all possible to spread the serialization code into multiple dependent DLLs? Just having something to hint at a possible solution would be a big help.
In recent versions of the library, the whole issue of spreading serialization implemenation across DLL s has recieved a lot of attention. It's a stick subject. First you should read the latest version of the documentation. Look at the latest explanation on EXPORT macros. Second, Look at the demo's and tests in the latest package. These specifically include cases of having Derived in a separate DLL than the base class and it's its interface. Examples of a "plug-in" are shows so that one could write his whole application around the base class interface and plugin a derived class implementation (including serialization) at some subsequent time - without rebuilding the main app! There are still some pending issues though. The library code has to ability to detect violations of ODR at runtime but this has been suppressed because too many applications have violations. In the future this will be resurrected as an optional feature. Robert Ramey