[boost] Re: Intrusive smart pointer

From: DKl_at_[hidden]
Date: 2002-04-19 11:35:50

Peter Dimov wrote:
> From: <DKl_at_[hidden]>
> > My point is that there should be one smart pointer type to be used for
> > passing "pointers" to 'T' around: This type appears in interfaces.

> There is. It's called shared_ptr.

Except, of course, that 'shared_ptr' is not a suitably configured for
certain situations: Notably, when you want to return 'this' the current
'shared_ptr' is no option. Also, my apparently false impression was
that people intended to replace 'shared_ptr' by some form of
policy-based smart pointer and this is clearly unsuitable (... and
would probably never pass the review process).

> This is not the end of story, however. For example, a factory that
> creates an object on the heap and transfers ownership to the user
> should return an auto_ptr, not a shared_ptr.

OK, an 'auto_ptr' is much more lightweight than a 'shared_ptr'. Is
there any other reason, too? If not, I wouldn't confuse people with
this optimization (many people are apparently inherently confused
without even considering their attempts to program such that I don't
think there is any need to add to this confusion). Of course, any
reasonable smart pointer implementation should probably be capable of
taking an 'auto_ptr' as constructor argument (in addition to plain
pointer): if using 'shared_ptr's is too expensive, this optimization
can be pulled.

> Similarly, a function that returns a pointer to an object derived from
> counted_base should return an intrusive_ptr, not shared_ptr.

Why? Why shouldn't 'shared_ptr' of such a type use the internal counter?
I can come up with two reasons resulting from ill-advised
implementations, neither of which I would consider worth supporting:
- When merely forward declaring a class prior to its first use in a
  'shared_ptr' it is unknown that it will later derive from
  'counted_base'. This can be circumvented by adding a correspondnig
  declaration indicating that the forward declared class will derive
  from a 'counted_base' later. I'm not sure but I think it can be turned
  into a link time error (at least) when this declaration is omitted at
  some use.
- When having non-intrusively counted bases are used, ie. if the
  intrusive count is added in the middle of the hierarchy. I think this
  is a bad idea and people would realize it when they try to assign
  things.

Although I can envision implementations of 'shared_ptr' which can
interoperate with 'intrusive_ptr' I think they come at some cost (ie.
even if 'shared_ptr' is never used together with an intrusive pointer,
some code is executed) and limit the flexibility of the 'shared_ptr'.
As a result, I don't think it is reasonable to separate the types.
--
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>