Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 09:07:52


"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "David Abrahams" <dave_at_[hidden]>
>> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> > news:004501c2c6f8$970c7400$1d00a8c0_at_pdimov2...
>> >> From: "David B. Held" <dheld_at_[hidden]>
>> >> [...]
>> >> Nope, but I want my sink strongly exception safe; the pointer should
>> >> be deleted when a policy constructor throws.
>>
>> BTW, this is also not the "strong guarantee" (I dunno, maybe people
>> mean something else by "strongly exception safe" -- is there a
>> definition somewhere?)
>
> Can't get away with colloquialisms.

Not in this area, sorry. Too many colloquiallisms, for too long, are
in large part what had poisoned people's ability to think effectively
about it.

> Yep, I am very wrong if the sink is smart_ptr::smart_ptr. Strong guarantee
> here means do-nothing, which is exactly what the current smart_ptr does,
> leak and all.
>
> I am less wrong if the sink is the expression
>
> smart_ptr<> px(new X);
>
> although this can give the strong guarantee only if "delete new X" has no
> observable side effects ; so "basic guarantee" is probably more precise.

That is a general assumption that underlies all of the guarantees.
It's a difficult corner to speak more-precisely about: to do so you
need to say something about which operations undo which other
operations. Anyway, we'd normally call that "strong" as well.

> And I'm even less wrong if the sink is
>
> px.reset(new X);
>
> since "basic guarantee" here says nothing about px after the exception. The
> exception safety of this construct has no name, it's somewhere between basic
> and strong.

Not sure what you expect the behavior to be in the face of an
exception, but I can't see why you say that neither named guarantee
applies here.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk