Boost logo

Boost :

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
> > 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
> for nearly half a decade now, so I would say that having a mutable count
> > In the general case, intrusive_ptr<> doesn't really know whether the
> > 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>
> > 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at