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

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-06-06 00:05:06

On 6/5/2010 7:08 PM, Chad Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/05/2010 03:49 PM, Marius Stoica wrote:
>
>>> [...] 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.
>
> I'm not sure what that would accomplish. The problem isn't that the
> classes can't communicate, it's that there's no way (short of either
> exceptions or setjmp/longjmp) to short-circuit the flow of execution --
> if we run into a problem in function H, then we have to send an error
> code back to function G, which has to check for it and send it back to
> function F, and so on, all the way to the point where the code knows
> what to do about it. That's a lot of redundant error-code checks.

Can you just call a user-defined or implementation-defined error 
handling function that won't return, e.g., std::abort?  Maybe just call 
throw_exception from Boost.Exception, which must be user-defined if 
exceptions are disabled.

Or do you actually, ultimately, want an error code sent back to the 
user?  I'm afraid I haven't been following the context of this 
particular sub-thread...

- Jeff