joaquin@tid.es wrote:
Robert Ramey escribió:
I'm aware that some problems occur when loading a map of objects containing other objects whose types are tracked or something like that. I forget the details. The problem is that when an object is moved and that object contains other objects which are pointed to by other objects, I'm speaking from memory but may one can get the idea ffrom that.
I think we're talking about the same thing.
I am not entirely sure... Let me restate the issue just to be confident I'm getting it through. Consider this pseudocode:
T t; ar>>t; v.push_back(t); // copy t somewhere else ar.reset_object_adress(&v.back(),&t); // and communicate it's been relocated
This works fine and subsequents pointers to t, when loaded, will point to the its new location inside v. Now consider the variation:
T* p; ar>>p; // *p is created and loaded automatically by Boost.Serialization v.push_back(*p); // copy *p somewhere else ar.reset_object_adress(&v.back(),p); // and communicate it's been relocated
This does not seem to work: objects created automatically by Boost.Serialization when loaded through a pointer cannot be relocated with reset_object_address: subsequent pointers to this object will point to the same object as p, not to the element in v.
Having a look at the source code of Boost.Serialization (basic_iarchive.cpp) it's apparent that moveable_objects_recent and moveable_objects_end are updated inside basic_iarchive::load_object, but are not inside basic_iarchive::load_pointer. Of course, I don't know what the hidden implications of updating these also in load_pointer could be, but I'd appreciate if you could comment on this.
OK, I looked into this. The list of tracked object that might be relocated as soon is the library is "done" with them. line # 392 moveable_objects_recent = this_id; That is when the stack is shortened. This keeps the list prety short. I would have to think about this some more.
T* p; ar>>p; // *p is created and loaded automatically by Boost.Serialization v.push_back(*p); // copy *p somewhere else ar.reset_object_adress(&v.back(),p); // and communicate it's been relocated
I presume that in your case something like the following wouldn't help? v.push_back(T()); ar >> v.back(); // assuming v.back() returns a reference Robert Ramey