Re: [Boost-users] [Serialization] Inconsistenttracking_level whenswitching from static to DLL

Subject: Re: [Boost-users] [Serialization] Inconsistenttracking_level whenswitching from static to DLL
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-12-01 15:21:19

Guy Prémont wrote:
>> This is a result of the serialization library maybe being a little
>> too smart for it's own good.
>>
>> The default behavior is to track if serialized as a pointer.  This
>> could vary if one invocation uses serialization of pointers and other
>> doesn't.  At one point I included code which would trap when the
>> serialization code for same type appeard in more than one DLL.  This
>> fixed the problem, but it required that users organize their code so
>> that serialization of a specific type be included in one and only one
>> DLL.  This turned out to be too onerous a requirement so I had to
>> comment out this check.
>>
>> So, I'm going to guess that the safest thing is for such types is to
>> either turn tracking off or on rather than using the default.
>>
>> Robert Ramey
>>
>>
>
> Thanks, it is what I thought. I am curious about the trap to check if
> serialization code is in several DLLs. What kind of code organisation
> are you talking about?
>
> In my case, the serialization code for a class T is in only one DLL,
> but it is used called by each DLL that contains serialization for a
> class that uses class T. The method T::serialize is in only one DLL.
>
> However, if class A has a member of type T it would have
> template<typename Archive>
> void A::serialize(Archive& ar, int version)
> {
>    ar & t; // where t is a T
> }
> As far as i see, it is the invocation of serialization in a serialize
> method (ar & t) that triggers the creation of the o/iserializer for
> type T. Is that it?

It is so you'd better use

template<typename Archive>
void A::serialize(Archive& ar, int version); // note ;

and include the difiniiton in the DLL

This is a murky area which I spent a fair amount of time
investigating some time ago.  Now I don't remember what
my final conclusions were.  I thought the problem manifested it
self in as "unregistered class" exception so that in the absense
of that, one could assume everyhing was kosher.

Robert Ramey