Robert Ramey wrote:
the de-serialization of a vector is somethng like:
template<class Archive, class T> void load(Archive ar, vector<T> & v){ unsigned int count; ar >> count; v.clear(); while(--count){ T t; ar >> t; v.push_back(t) } }
From my reading of the weak_ptr document, a weak_ptr cannot point to anything if there is no existent correspnding shared pointer. So the
above
would necessarily fail unless a shared_ptr was previously serialized in
Truth is, the scenario you describe never occurred to me. It might be addressable with a more elaborate implementation of weak_ptr serialization than I proposed - but maybe not. I'll have to think about it some more. Robert Ramey "Russell Hind" <rh_gmane@mac.com> wrote in message news:cnmmt0$7jk$1@sea.gmane.org... the
same archive - which is not guarenteed. In order to use such a data structure, the default implementation of the serialization of vector would have to be overriden.
From a users's point of view, how I'd expect/like this to work is that if a weak pointer is serialized first, then the actual shared object is serialized. On the way back in (loading) the weak pointer can be read and will point to a valid shared object *until* the archive is closed. At that point, if the user doesn't have a shared_ptr to the object, then the object is deleted but up until then, the weak_ptr is valid.
Yes it is ultimately a user error to serialize *only* a weak pointer, but I don't believe it should be a user error to serialize a weak_ptr before a shared_ptr. IMHO, the library should keep the object alive (i.e. hold a shared_ptr to any de-serialized pointers, shared or weak) until the archive is closed.
But I haven't really looked at the implementation of shared_ptr and serialization, so this is just how I'd 'expect' it to work
Cheers
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost