Re: [Boost-users] [serialization] Implementation in mutliple DLLs

Subject: Re: [Boost-users] [serialization] Implementation in mutliple DLLs
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-09-08 12:53:21

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