Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Peter Dimov (pdimov_at_[hidden])
Date: 2010-03-30 17:17:45

Chad Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 03/30/2010 11:45 AM, Peter Dimov wrote:
>
>>> Which is only a problem if you're doing something that produces a NaN.
>>> In XInt, that's rare, and all such cases are very carefully documented.
>>
>> Right. What is the purpose of the NaN? Its function is to delay the
>> exception until the first use of the result, making the point of the
>> erroneous calculation harder to trace. In what scenario is this a good
>> thing?
>
> If you ignore NaN results from functions that return them, then yes,
> that is the result. If you use them properly, and check for NaN as soon
> as a function that can return it returns, you will know the exact line
> that it came from.

So, in other words, the purpose of the NaN is to be a "throwing error code". 
You are supposed to always check for it, and if you omit a check, it throws 
when someone looks at it.

> In what scenario is this a bad thing?

In general, but this leads us into the generic exceptions vs error codes 
debate. Error handling philosophies aside, in this specific case, I don't 
see how checking the result of every op/ for NaN is in any way better, more 
readable or more expressive than checking the denominator for being zero 
beforehand, but to each his own.

> I'm sorry you don't see the logic behind it. I do, and n1744 (the
> "standardese" for the large-integer library proposal) specifies it, on
> page two: "all integer operations which return an (temporary) integer
> and many member operators may fail due to insufficient memory. Such
> errors are reported as overflow_error exceptions (as available memory
> defines the range of the integer class)."

I see the logic, I just don't agree with it. Term abuse aside, the correct 
response to std::bad_alloc (making more memory available, if possible) 
typically differs from the correct response to std::overflow_error. If you 
insist on masking std::bad_alloc, it would be better to choose a distinct 
type so that people can treat it as a bad_alloc.