Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-05 11:46:41
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk