Boost logo

Boost :

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-05-19 14:01:01


> Some time ago the question was raised on this list as to why
> it was necessary to access share_count in order to implement
> serialization of shared_ptr. At the time I didn't have an answer.
>
> So I went back and tried to re-implement it and have come to
> the following point beyond which I can't proceed without
> manipulating shared_count directly.
>
> /////////////////////////////////////////////////////////////
> // implement serialization for shared_ptr<T>
>
> template<class Archive, class T>
> inline void save(
> Archive & ar,
> const shared_ptr<T> & t,
> const unsigned int /* file_version */
> ){
> ar << boost::serialization::make_nvp("px", t.get());
> }
> 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<int> member;

    load(...) {
        ar >> member;
    }
};

A a1, a2

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.

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk