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