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

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-29 13:39:19

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

> 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. ;)  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, 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. :(

Dave