From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-11 00:04:16
> shared_ptr does it by having 2 pointers to the object. The first is
> stored in shared_ptr::pn. It points to the start of the object. The
> second, which may point to inside of the object after conversion from
> the most derived class, is shared_ptr::px.
This is obviously redundand. I was hoping this situation to be undefined
because I was following raw pointer behaviour which is the closest to the
In the worse case situation I could just start writing a virtual table at
compile-time [for non-polymorphic objects] which I already did once.
>> really negligeable, believe me.
> Well, the only reason I mention it is because some "authorities"
> have mentioned it. For example, in Jones&Lin's _Garbage Collection_,
> The most serious disadvantage is the high processing cost...paid to
> update counters to maintain the reference count invariant.
I am not sure what this means but I guess he is talking about accessing a
reference count without modifying its content.
I would like to work on this full-time because this is not a delicate
subject. Thanks again for pointing those points out; you are pretty much
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk