[boost] Re: shifted_ptr review

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-11 00:04:16

cppljevans_at_[hidden] wrote:

[...]

> 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
standards.

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_,
> p.24:
>
>    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
smart.

Philippe