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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 12:34:27

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uptqg32x2.fsf_at_boost-consulting.com...
>> [...]
>> I was half-joking.  Imagine you used an auto_ptr in the
>> implementation of SmartPtr<>.
>> [...]
>
> Well, help me reason this out anyway, because this is a gray area for me.
> We would have to put the auto_ptr<> in a StoragePolicy (otherwise,
> you defeat the point of PBD), 

I'll take your word for that.

> and then we would have to make sure that the StoragePolicy was the
> first member to get initialized, right?  

Yeah, sounds right.

> Then we would have to guarantee that StoragePolicy is no-throw, or
> we defeat the whole purpose of this little game, right?  

Hmm, no.  The contract would have to be that if StoragePolicy throws
an exception, it frees the resource passed as its constructor
argument.  There's nothing wrong with a requirement like that in
principle.

> That means that StoragePolicy() will always succeed, and thus, the
> StoragePolicy sub-object will be fully constructed before any of the
> other policy constructors are called?  

"Mu" (ask Terje to explain)

> Then, if one of the other c'tors does throw, the StoragePolicy d'tor
> will get called, even though the SmartPtr is not fully constructed,
> and that will clean up the resource?  Or am I missing something?

A little, but you mostly got the picture right.

> It seems that the function try block is slightly more powerful,
> because it does not require StoragePolicy() to be no-throw.

Yes and no.  

1. Aren't function try blocks somewhat non-portable in practice?
2. Isn't it onky the StoragePolicy that knows how to free the resource?

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