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
>> (*) 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk