[Boost-users] [Serialization] Inconsistent tracking_level when switching from static to DLL

Subject: [Boost-users] [Serialization] Inconsistent tracking_level when switching from static to DLL
From: Guy Prémont (guy.premont_at_[hidden])
Date: 2010-12-01 13:13:27

Hi,

 

I am using boost (1.40) serialization on Windows (VS 2008) to serialize a
complex hierarchy of classes.

 

My application is composed of different modules, each having its own
serialization library. I have a Core library, with a CoreSerialization
library, that defines a bunch of classes and base data types; I also have a
Vehicle library, with a separate VehicleSerialization library, the defines
some other classes with base classes in Core and that also use some user
data types defined in Core. Using static libraries, everything saves and
loads perfectly.

 

We recently switched to using DLLs. When loading and saving with an
application that only uses core (as Dlls) everything serializes perfectly.
We can load files that were generated by an older application (using static
libraries), save them and load them back.

 

If the application also uses the Vehicle libraries, it can load older files
(generated using  static libraries), save them, but fails to load them back.

 

The difference between the files generated with a DLL application and a
static link application, lies in the tracking of certain classes. Since the
serialization is split between 2 DLLs, the tracking level (by default
selectively) will actually depends on what classes are serialized in the DLL
and may be different in different DLLs. 

 

This seems to be cause by the various singleton that are created, notably
pointer_oserializer<T> and oserializer<T>. In a statically linked
application, there is only one instance on those singleton, in a DLL linked
application, there is one instance of the singleton for each DLL.  I've also
noticed that in my Core DLL, for certain type, there are both notably
pointer_oserializer<T> and oserializer<T>, while in the Vehicle DLL, there
is only notably oserializer<T>, hence the difference in tracking level.

 

There is an easy fix here, not to use selective tracking but track always or
never, explicitly. But still, there seems to be some data that needs to  be
shared across various serialization DLLs. I am a bit worry about some other
bugs popping out relative to it.

 

Has this bug ever been found? It may be a side effect of putting
serialization code in DLLs, the documentation on that subject is a bit
sparse.

 

Thanks for any inputs

 

Guy

--
Guy Prémont, D.Sc.
Architecte logiciel senior / Senior software architect
CM Labs Simulations Inc.  <blocked::http://www.cm-labs.com/>
http://www.cm-labs.com/
Tel. [phone] ext. 237