From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-15 20:36:00
> 1. Exception behaviour occurs only for sharing, not for acquisition
That is a true statement, but does not explain an advantage.
> 2. The object that is being acquired is not jettisoned at the first sign
> of trouble.
This characterization is frought with bias. It condemns with its tone
without explaining why there is a problem with the current behavior (if any
Please note that the current behavior of the constructor is similar to
passing ownership of the object with an auto_ptr. Ownership is assumed by
the constructor immediately upon its invocation.
> 3. The functions that could throw exceptions are clearly defined.
I don't see how that's any different from the current situation.
> 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
Describing the first model as "lossy" again condemns without explaining any
disadvantage. Is it your intention that the shared_ptr should take (shared)
ownership of the body object? If so, the body will certainly be deallocated
when the last shared_ptr is destroyed. In what sense is that less "lossy"
than in the existing model?
> 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.
(Many good implementations of exception handling will incur no runtime cost
for these recovery actions.)
Usually you want a shared_ptr because you want to optimize copying. There's
already a presumably large overhead at initialization time because of the
dynamic allocation and construction of the body. Please give a concrete
example where it would be useful to optimize for initial construction of the
handle at the expense of copying.
> 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.
No, it would only be a leak in the most natural and obvious case of
initializing the shared_ptr.
> 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,
What caveat do you have in mind? In what way doesn't it conform to its spec?
> and if shared_ptr adopts the second
> set of semantics it becomes a closer and more subsitutable relative of
This is the first time you've hinted at a real advantage to your suggested
semantics. I buy that argument, but I don't think it outweighs the
disadvantages, in particular that copying can throw.
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