From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-17 11:14:14
From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > 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 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.
The choice _is_ left 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>
> > 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
There are four types of smart pointers being discussed here:
1. intrusive_ptr<X>, general case
2. intrusive_ptr<Y>, Y is-a counted_base
3. shared_ptr<T>, using a detached count
4. shared_ptr<T>, constructed from something that is-a counted_base, and
using the embedded count.
(2) is convertible to (4), and (3) and (4) interoperate freely (they are the
With (1), the user is expected to define intrusive_ptr_add_ref/release that
are able to take an X*. If these user-supplied definitions take const
pointers (X::count is mutable), intrusive_ptr<X const> will work.
With (2), the decision on whether counted_base::add_ref etc should be const
is still up in the air. I have deliberately left the count non-mutable to
acquire some experience about the potential problems that this may cause
(encountered none so far.)
It is true that shared_ptr<Y> will work; the only difference is that
sizeof(shared_ptr) is twice sizeof(intrusive_ptr).