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 11:45:22

Chad Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/30/2010 08:23 AM, Peter Dimov wrote:
>
>>> How does one mix code wanting exceptions with code not wanting them?
>>
>> Pretty easy (bad_alloc aside (*)), since the only way to get an
>> exception when doing integer operations is to divide by zero (**). So
>> code not wanting exceptions needs only not divide by zero - problem
>> solved. This of course assumes that the exceptions are not delayed via a
>> signaling NaN with the express purpose of making your life difficult by
>> turning unary op+/- into a throwing operation.
>
> 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?

>> (*) And by the way, out of memory is not overflow. It's possible to run
>> out of memory while computing an integer that is smaller than another
>> integer that already has been computed. This is not what overflow means.
>
> If that was aimed at XInt, note its purpose: it's intended to allow
> calculation with numbers of arbitrary length, up to the memory size of
> the system. If the system can't provide enough memory for it at some
> point, that *is* an overflow -- the number is too large to represent.

No, it isn't an overflow. An overflow doesn't occur at random, depending on 
some external resource. Overflows are deterministic and depend on the fixed 
range of the number. A 32 bit signed integer always overflows at 2^31. If a 
calculation produces a number X without overflowing, that same calculation, 
when performed again, will still produce X without overflowing. This is not 
true for out of memory conditions. Arguing that making a copy of a number 
can overflow is stranger still.