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.