[boost] Re: Misc library documentation issues

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
to
>    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
out
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
the
>    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
constructed?

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.

   Kevlin

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications