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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-30 17:48:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2010 05:17 PM, 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.

As I said above, it's extremely rare that a function will return a NaN.
There are only two functions in the library that do so under normal
circumstances, both carefully documented. If the user is blocking
exceptions, there are a handful of others, also carefully documented.

Where am I explaining things wrong, that everyone seems to think that
any function can randomly return a NaN, and is complaining about it on
the basis of that misconception?

>> 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.

That's a good reason, and your suggested solution is easy to implement.
I'll do so for the next iteration.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuycZQACgkQp9x9jeZ9/wT1sACeOCDoPoKc3bzAeznilP2OMXWX
WL4An2UUoDxiupaYk5bCodQbiV4qPJv5
=CQ3q
-----END PGP SIGNATURE-----