RE:RE: [boost] seiralization of shared_ptr

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-05-20 10:30:50

>> template<class Archive, class T>
>> inline void load(
>>     Archive & ar,
>>     shared_ptr<T> & t,
>>     const unsigned int /* file_version */
>> ){
>>     // object tracking guarantees that pointers are not replicated
>>     // on loading.
>>     T * t_new;
>>     ar >> boost::serialization::make_nvp("px", t_new);
>>     // if its not the first time, it should be equal to the  current
pointer
>>     assert(0 == t.use_count() || t.get() == t_new);
>>     // assign new pointer or bump reference count as appropriate
>>     // ???? - what goes here?
>> }
>> 
>> Can anybody tell me "what goes here?"
>> 
>> Robert Ramey

>I don't see problem where you see it. I ses problem in different place.

>How is it possible that t.use_count() != 0? My understanding that before
>loading all data is empty and you never actually load the same variable
>twice.

>struct A {
>   shared_ptr<user_type> member;
>   load(...) {
>       ar >> member;
>   }
>};

>A a1, a2

At this point a1.member.use_count == 0,

>ar >> a1;
>ar >> a2;
...

>Now the real problem lies IMO in a fact that you need to keep map raw ptr -
>corresponding shared_ptr. IOW when you got raw ptr and you need to create
>shared ptr for it you need to figure out somehow whether you already did 
>it. If yes you need to make a copy to that shared_ptr. If not create new
>and register it.

That's the problem. There's no way I can see to create a copy of an existing
shared pointer given only the copy to the shared underlying pointer.  

The current implementation uses object tracking to load the replicated
pointer to the shared_count.  At that point the loaded shared pointer is
connected to any other shared_ptrs that correspond to the underlying shared
object.  This does not require maintenance of any other ptr/shared_ptr maps
which would only replicate the what the serialization library does anyway
through object tracking.  However, the current method does require either
privileged access to shared_ptr and shared_count or some sort of expansion
of the interface.

I believe this answers the original question you posed:"Why does
serialization of shared_ptr require access to shared_count?"

Robert Ramey