Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Marius Stoica (letto2_at_[hidden])
Date: 2010-06-05 15:49:36

On Saturday 05 June 2010 18:46:41 Chad Nelson wrote:
> On 06/04/2010 05:50 AM, Marius Stoica wrote:
> > I just realised that nothrow integer wouldn't compile with
> > -fno-excetpions. I was assuming that was it's point. I was thinking
> > maby instead of using exceptions you could do something like this in
> > the implementation
> > 
> > if (n = maloc(...) == NULL) exceprion_fun(out_of_memory);
> > that could be a function that throws with exceptions and handles the
> > error for nothrow.
> 
> I've been wrestling with this, and I've hit a dead end: the no-throw
> version of exception_fun would have to somehow emulate an exception by
> somehow unwinding the stack back to the point where I'd normally catch
> the error.
> 
> There are only two ways that I can see to do that, without exceptions.
> The first is to test the return value of *every* call, and if it says
> there was an error, return the error value from it -- very annoying to
> code, and I see no way to implement it that wouldn't increase the code
> size, decrease the speed, or both.
> 
> The second is to use setjmp/longjmp. That doesn't sound like a good
> idea, since it apparently doesn't do cleanup stuff like calling
> destructors.
> 
> The only solution I see is the way I'm handling the nothrow_integer type
> already: wrap every top-level call in a try/catch construct. Unless
> someone can suggest some way to handle stack-unwinding without
> exceptions, doing it manually, or setjmp/longjmp, I don't see any viable
> way to change it.

What about having a pointer in the contained classes back to the upper one ?
I think you can make it be there only for the no-exception classes by adding 
it to a no-exception policy class and inheriting it.