"David B. Held" <[EMAIL PROTECTED]> writes:
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> 004501c2c6f8$970c7400$1d00a8c0@pdimov2">news:004501c2c6f8$970c7400$1d00a8c0@pdimov2...
>> From: "David B. Held" <[EMAIL PROTECTED]>
>> [...]
>> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
