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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 01:06:49

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:ulm15gj97.fsf_at_boost-consulting.com...
>> [...]
>> BTW, this is also not the "strong guarantee" (I dunno, maybe people
>> mean something else by "strongly exception safe" -- is there a
>> definition somewhere?)
>
> Does it even make sense to say that a c'tor provides the strong
> guarantee?  

Yes, but saying so has limited power.  Any constructor providing the
basic guarantee also provides the strong guarantee unless there's
global state involved.

> It seems that the strong guarantee is more appropriate
> for describing operations on fully constructed objects.

Not sure why.  An operation is an operation is an operation.  Don't
forget, whole-program state goes beyond the state of "the object in
question."  That's a fact that most people analyzing exception-safety
seem to overlook.

>> [...]
>> 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?
>
> So if I understand you correctly, you're saying SmartPtr *should*
> take ownership regardless of whether a policy c'tor throws, and thus,
> when a policy c'tor throws, the SmartPtr should do the right thing and
> free the resource?

>From a usability point-of-view, that sounds like the best answer,
wouldn't you agree?  It has nothing to do with the strong guarantee,
though.

>> [...]
>> You don't need that; you can just use a smart pointer member
>> <0.5 wink>
>
> Sorry, I don't follow.  Do you mean that SmartPtr<> should really
> be a wrapper for the implementation, and it is the implementation
> that actually calls the policy c'tors?  Even then, I don't see how you
> can get away from having to catch an exception from an initializer
> list.

I was half-joking.  Imagine you used an auto_ptr in the implementation
of SmartPtr<>.

>> > [...]
>> > 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.
>
> Well, what I meant was that people don't necessarily write a smart
> pointer with the full auto_ptr semantics.  More often, it turns out to
> be something like scoped_ptr.  But the people I know who do that
> tend to not know about the Boost pointers in the first place, and
> think they are inventing something cool because they understood
> enough about auto_ptr<> to make their own version with feature
> X (though usually not with the full move semantics).

OK, not sure that addresses Peter's question, but... "Whatever" with a
big Texas-sized dubya.

-Dave

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