Re: [boost] Logical constness of intrusive_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-17 10:37:58

From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > From: "Ed Brey" <brey_at_[hidden]>
> > > Currently intrusive_ptr<T const> is not supported, ultimately because
> > counted_base::use_count_ is not mutable.  To me it seems like the count
of
> > references to an object are unrelated to its logical constness.  What do
> > others think?
> > <
> >
> > Nontrivial question. I don't have enough experience with it yet in order
> to
> > decide.
> >
> FWIW, my own intrusive pointer uses a mutable count. It's been working
fine
> for nearly half a decade now, so I would say that having a mutable count
is
> OK AFAICT.
>
> > In the general case, intrusive_ptr<> doesn't really know whether the
count
> > is part of the object state. It all depends on how intrusive_ptr_add_ref
> > (release) is defined for the specific type; if it takes const pointers,
> > intrusive_ptr<T const> should work fine.
> >
> I think it should take const pointers.

My point was that intrusive_ptr<> doesn't constrain this in any way; it's
your choice.

> > In the specific case of objects derived from counted_base, either choice
> > seems plausible, since there's the option of using shared_ptr<T const>
to
> > denote const objects.
> >
> I think counted_base::add_ref(),release(),dispose(),etc.. should all be
> const.
>
>
>
> P.S: I noticed while inspecting the latest boost code that
> 'intrusive_ptr.hpp' doesn't include 'detail\shared_count.hpp'.
> Should it? I might want to use only intrusive_ptr<>, not shared_ptr<>.

intrusive_ptr, by itself, doesn't depend on counted_base, but you are right
that counted_base should probably live in its own separate (non-detail)
header, boost/counted_base.hpp perhaps.