On 2/7/17 4:20 AM, Robert P wrote:
The faulty behavior is in that the objects are 1) not references or pointers, but local instance variables so should not be tracked, 2) contain unique data and should not be referenced to other objects even if they were pointers, and 3) do not unserialize correctly, instead resulting in objects with default values.
Does boost keep a global table of reference tracking values that does not get reset between serializations? That would possibly explain the problem.
The serialization library does not track object contents, only their addresses.
I was able to disable object tracking and it works now,
This is the correct solution
don't think it should be doing object reference tracking on instance variables.
I think if you spent more time considering this this, you'd change your opinion. Is it because of the template wrapper
around vector?
Not relevant The question is really about what it means to serialize something on the stack. Something like MyT my_object; ... // serialize/deserialize my object Is going to be fine. But something like ... for(...) MyT my_object; ... // serialize/deserialize my_object or worse MyT::serialize(ar, version) const { x = f(*this) ar & x; } is going to be asking for trouble as we're reusing the same address. As you've discovered. the library provides a work around for this. But when confronted with the need to use it, it should be seen and an opportunity to step back and ask oneself: "Is this really what I want to do? Why am I saving the state of something that is changing?" Robert Ramey