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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk