Robert Ramey ha escrito:
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41AEC3AE.21D594CB@tid.es...
cont.begin(): 1 pos points to: 1 cont.begin(): 1 pos points to: 1243388
illustrating that the pointer is not correctly deserialized.
OK, I see it now.
I tweaked your example a little but it still fails.
In my view - it should work. The fact that it doesn't reflects an implementation issue with the serialization library with respect to its implemenatation for standard containers.
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(); 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: * 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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo