From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-19 11:48:29
> > 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?
Yes. Having an auto_ptr means that I'm the only owner of the object. I can
> 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'.
shared_ptr, as currently implemented, _can_ interoperate with intrusive_ptr.
Essentially no changes to shared_ptr are necessary (except adding the
conversion constructor.) We have already paid for the flexibility that the
embedded shared_count offers.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk