Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-28 14:35:32

"David B. Held" <dheld_at_[hidden]> writes:

> "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?)

This behavior is basic exception safety, depending on the
documentation of the sink.  In other words, it's "fine" to make a
class whose constructor takes posession of a resource only if it
succeeds, as long as it's so documented:

        std::auto_ptr<X> p(new X);
        sink s(p.get());
        p.release();

The problem is that it's not very usable when the resource is passed
via some unmanaged mechanism like a raw pointer, because then you need
to protect it with something like an auto_ptr, and in the case of a
"do everything smart pointer" that's really somewhat silly isnt it?

> Hmm...that's not a bad point.  A function try block should make this
> possible, no?

You don't need that; you can just use a smart pointer member <0.5 wink>

>> [...]
>> Yes, I understand that, but do you know of a user that needs an
>> almost_auto_ptr? ;-)
>
> Given how often people write auto_ptr<> without writing auto_ptr<>,
> I'd say yes. ;>

Not a challenge, but can you give an example?  I've never seen it and
I have trouble imagining why someone would do it.

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