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.