"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41AF68C7.B68D7CF4@tid.es...
Your original observation that the container de-serialization doesn't do inplace construction is the source of the difficulty. My interest would be to see this re-considered to see if its possible to use in-place construction - similar to the way its done for most other pointer like objects. Somehow it doesn't seem that this should be all that hard.
I'm pretty sure it is in fact impossible with the current functionality offered by Boost.Serialization. I'm saying this after thinking about the issue for a good couple of weeks while designing multi_index serialization. The problem could be solved for std::lists:
// load en alement into the list l.push_back(element_type()); ar>>&li.back();
I remember now, this created problems for types without default constructors.
but this approach cannot be applied to associative containers like sets: one cannot just preinsert the element before loading the value, cause insertion *depends* on the value. It's a chicken and egg situation.
IMHO this problem necessitates some facility to let the user fine-control tracking, in the spirit of the two features I proposed a few posts ago:
OK - I'm convinced. I'm not motivated to change anything yet, but I can see the problem.
* reposition a track address * make_external for allowing tracking to an object which is not serialized itself.
I can elaborate on how this could solve the problem, if you'd like. feel free. Robert Ramey