|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-05-20 11:46:52
> >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.
I wouldn't say that.
You could use simple map<void*,void*> that mapr raw pointer to an address of
shred_ptr, It is a bit havyweight and does partially replicate what library
core is doing (that is why I called it " more complex solution" in original
post). But I believe it quite unique situation that varant special
treatment.
> 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.
So the question is what tradeoff you prefer:
1. You pay for an extra space to store ptr->shared_ptr map and possibly(?)
exra time
2. You pay with extra space in any archive that uses shared_ptr and demand
access to shared_ptr private area
Actually who has time advantage it not simple question. My understanding is
that in second case you still spend time on reading counter from archive
searching in resistry and extr maintanence work.
> I believe this answers the original question you posed:"Why does
> serialization of shared_ptr require access to shared_count?"
I would go with direct map.
> Robert Ramey
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk