[boost] Re: Logical constness of intrusive_ptr

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-17 10:46:47

"Peter Dimov" <pdimov_at_[hidden]> wrote in message news:00ce01c22d9c$38191070$1d00a8c0_at_pdimov2...
> 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 understand.  And the constness of intrusive_ptr_add_ref ultimately relies on the constness of the count object, when there is one.  If there are valid reasons to have the const object be either const or non-const, I suppose the choice sould be passed up to the user.

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

This is close to an argument against the existence of intrusive_ptr in general.  If shared_ptr is viable for const T, then why not for non-const T also?