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
> would be copying operations (ie cp ctor and op=), but in such cases
> would not result in the loss of the held object, only the failure to
Please explain the advantage of these semantics. Of course we could make
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
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
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
important to know that certain operations don't throw so you can use them
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
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