[boost] Re: Misc library documentation issues

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
exists).

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.

-Dave

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

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