Re: [boost] Logical constness of intrusive_ptr

From: Brad King (brad.king_at_[hidden])
Date: 2002-07-17 10:03:43

On Wed, 17 Jul 2002, Peter Dimov wrote:
> 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.
>
> 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.
>
> 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 was recently exposed to this exact question in a project that defines
its own intrusive smart pointer.  The developers originally concluded that
the logical constness of an object is independent of the reference count,
and then made the refcount mutable.  About a year later, we came to regret
that decision when threading issues started popping up.  The project uses
const-ness to help maintain thread safety (it assumes that const objects
can be used inside threads without a critical section).  Since the
reference count was not also const for these objects, we ended up having
to add a mutex around the reference count adjustments until a few sweeping
changes could be made to avoid adjusting the reference count of a shared
object inside a thread.

I don't know if this helps your decision or not, but it is one story from
experience.

-Brad