Boost logo

Boost :

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
> object.

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
> scoped_ptr.

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.


------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at