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

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-29 14:26:06

"David Abrahams" <dave_at_[hidden]> wrote in message
news:usmvbrcxi.fsf_at_boost-consulting.com...
> [...]
> "They" meaning function-try-blocks?

Yes.

> 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.

So I've heard.

> [...]
> > 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.

Unfortunately, StoragePolicy doesn't know when other c'tors have
failed.  The only one who does is smart_ptr, which is why it seems
I have to either A) use a function try block to inform StoragePolicy
that someone else has failed, and clean up appropriately, or B) not
use initializer lists, and do all the work in the c'tor body of smart_ptr.
It seems to me that neither is a particularly attractive alternative,
although, I see that shared_count goes by way of B).

Dave