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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 14:08:57

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uadhjuafw.fsf_at_boost-consulting.com...
>> [...]
>> 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.
>
> I see.  We don't need StoragePolicy to be constructed.  We just need
> it to be constructed before everything else.  Makes sense.
>
>> [...]
>> > 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?
>
> Are they?  You mean because they aren't implemented well?

s/well/at all/ in some cases IIRC.

>> 2. Isn't it only the StoragePolicy that knows how to free the
>> resource?
>
> Hmm...technically yes.  If the StoragePolicy were fully constructed,
> you could ask it to free the resource.  But then you're requiring it
> to be no-throw to begin with.  So it seems that they give you
> nothing, as usual. ;)  

"They" meaning function-try-blocks?

The rule I have stuck in my head from the last time I considered this
was: all they give you is the ability to translate the exception into
some other exception.  I never thought that was a particularly
valuable thing to do in most cases.

> Unfortunately, neither does a managed pointer in the StoragePolicy.
> Sure, it frees the resource in the presence of exceptions, but it
> also frees it in the absence of exceptions, 

Huh?  No way.  If it were a member of the StoragePolicy, it wouldn't
be a problem.

But I'm not seriously suggesting that you do this, because it still
wouldn't be freed according to the StoragePolicy if you used,
e.g. auto_ptr.

> which is quite too often.  Namely, it doesn't know when it
> *shouldn't* free the resource, because it doesn't know about
> Ownership.  So now it looks like we're back to that pesky function
> try-block, and requiring StoragePolicy to be no-throw. :(

I can't agree with your conclusion.  IMO the right answer is that
StoragePolicy promises to free the resource it's initialized with when
construction fails.

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