Re: [boost] Re: Logical constness of intrusive_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-19 11:07:53

From: "Ed Brey" <brey_at_[hidden]>
>
> > > 4. I was happy, except for the cases where I my new code had
> > intrusive_ptr<T const>.  So I changed those to back shared_ptr.  I also
> > noticed that given T const, shared_ptr silently pessimized by not using
> > counted_base,
> > <
> >
> > Could you elaborate? What does "not using counted_base" mean here? This
may
> > be a bug.
>
> The shared_count constructor overload that takes counted_base* does not
take counted_base const*, which is what it would get if the shared_ptr's
template type is <T const>.  Overload resolution then falls back on the
templatized constructor, which uses the heap instead of counted_base.
<

No, whether the template parameter is const or not doesn't matter. In

shared_ptr<T const> pt(new T);

the type that pt has been initialized with is 'T', not 'T const', just like
in

shared_ptr<T const> pt2(new Y);

'pt2' is initialized with 'Y'.

The only place where the 'counted_base const *' problem appears in practice
(AFAIK) is:

class X: public counted_base // allow this -> shared_ptr conversions
{
public:

    shared_ptr<X> shared_this()
    {
        return shared_ptr<X>(this); // OK
    }

    shared_ptr<X const> shared_this() const
    {
        return shared_ptr<X const>(this); // should be a compile-time error
//      return shared_ptr<X const>(const_cast<X*>(this)); // not pretty but
OK
    }
};

If your experience differs from match my explanation, then I've probably
done something wrong. :-)