[boost] Re: Misc library documentation issues

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1999-07-15 09:00:31

> The count of 1 could be introduced as a static and would be the initial
> value for any given pointer. The only operations that could lead to
failure
> would be copying operations (ie cp ctor and op=), but in such cases
failure
> would not result in the loss of the held object, only the failure to
share
> it:

Please explain the advantage of these semantics. Of course we could make
the
change, but what's the point?

   1. Exception behaviour occurs only for sharing, not for acquisition
   2. The object that is being acquired is not jettisoned at the first sign
   of trouble.
   3. The functions that could throw exceptions are clearly defined.

I consider it valuable to be able to copy and assign without throwing
exceptions. It is very convenient when implementing handle/body classes.
Once the entire handle/body package is created, it can be copied as often
as
desired with no concern for exceptions being thrown. Regardless of which
technique is used, the construction and allocation of the body part can
always throw an exception, so it is better to localize all of the exception
throwing in one place rather than spread it across the operations. It can
be
important to know that certain operations don't throw so you can use them
in
recovery actions.

   In both cases there are the same number of operations that could throw,
   but they are different in each case, ie acquisition in the first model
   and sharing in the second. The second model is non-lossy wrt the body
   object. The second model also offers an allocation optimisation for
   certain uses. In terms of recovery actions, the way I see it, the second
   model requires less in the way of recovery.

   I want to be clear that I am not saying that there is anything wrong
   with shared_ptr as it stands -- far from it, it offers good
   functionality through an exception safe implementation (although throw()
   could be used more consistently to reinforce which functions are
   non-throwing) -- it is simply that I would like to discuss a possible
   shift in failure semantics and allocation strategy. The issue worth
   discussing arises from the ctor fix tagged "fix: prevent leak if new
   throws", when it is not altogether clear that this will _always_ be a
   leak given the user's requirements and calling context.

   A careful reading of the documentation and comments indicates that the
   implementation does not quite conform to its spec: there is no caveat
   wrt partially constructed objects, and if shared_ptr adopts the second
   set of semantics it becomes a closer and more subsitutable relative of
   scoped_ptr.

   Thoughts?

   Kevlin

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

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