From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1999-07-14 08:12:33
> I would tend to disagree: auto_ptr got broken because simplistic
> features were added to it -- in terms of design, they introduced more
> problems than they solved. That this was (and is) the case is simple
> demonstrate, which begs the question of why that design went off the
> rails in the first place (that was rhetorical >:->).
Reasonable people could disagree about this. Personally, I feel the current
auto_ptr design is superior to any of the previous ones (once you figure
how to implement it - a non-trivial job)!
The current auto_ptr design almost wasn't, and it does indeed resolve
many of the problems -- it is w/o a doubt superior to any that appeared
in the WP from just before CD1 onwards. What I was mainly referring to
was the troubled history of auto_ptr, and how it got that way.
> However, returning to the point, the idea of adding a nocount is not
> really adding a new type of smart ptr at all. It simply allows more
> flexible use of the library. The introduction of a shared count for 1
> allows a simple optimisation for a common case, and a resolution of
> construction problem (ctors would then never fail).
Why do you think that it's less problematic to have a smart ptr that can
throw when copied and assigned than one that can throw when initially
Personally, I find the exception behavior of shared_ptr quite convenient.
The distinction is that shared_ptr as exists opens up the possibility of
immediate object loss (by deletion rather than leak) on acquisition of
ownership. What I was sketching out (whether or not it is taken up by
shared_ptr is another matter) was a scheme I have used where the
possibility of failure occurs when the object is shared, not when it is
initially acquired, and therefore object loss does not occur. This also
acts as an optimisation for cases where sharing does not occur.
In short, the two schemes differ in terms of quality of service.
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk