Boost logo

Boost :

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-05 11:46:41

Hash: SHA1

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.
- --
Chad Nelson
Oak Circle Software, Inc.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Boost list run by bdawes at, gregod at, cpdaniel at, john at