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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-03-29 00:57:19

On 28 March 2010 23:56, Chad Nelson <chad.thecomfychair_at_[hidden]> wrote:
>
> And it's an excellent question. The only justification for making it
> non-blockable is that, if it were blockable, then nearly every function
> in the library could potentially return a Not-a-Number value, and you'd
> have to check for it constantly when blocking exceptions. That would
> defeat the intended purpose of the exception-blocking mechanism (see
> below). As it's not, you only have to check for the Not-a-Number value
> on the few functions that can throw a blockable exception.
>
> The mechanism isn't there so that the exception-hating crowd can get
> away with avoiding exception-handling. It's there to give the developer
> using the library the flexibility to treat its functions as returning
> error codes, rather than throwing exceptions, when it would make for
> more readable code.
>

You advocate Signalling NaNs.  That means that you haven't actually
made your checking any easier by blocking exceptions, because if you
pass a result to anything else, it still needs to be checked.  Since
you said earlier that the most complicated look-before-you-leap[1]
check required to avoid an exception is "x < 0", I fail to see the
advantage, since there's just as much code required and no speed
advantage.  In fact, there may well be a speed disadvantage, since now
every single function that takes in an XInt has to check "x.isNaN()"
before doing anything.  In fact, the only place where
couple-leaping-with-looking[2] is advantageous is the overflow
exception, so that's the only one where being able to block it could
make a substantial readability improvement in my code.  (Quiet NaNs
may as well, since I could check once at the end instead of before
every function call that throws when given a signalling NaN.)

[1] http://www.c2.com/cgi-bin/wiki?LookBeforeYouLeap
[2] http://www.c2.com/cgi-bin/wiki?CoupleLeapingWithLooking

>
> There's no other logical response if there's no cryptographically-secure
> random number generator, and the user asks the library to instantiate
> one. (That's not in the version that was uploaded to the Boost Vault
> yet.) And it's debatable whether there's any other consistent and
> mathematically logical way to handle passing Not-a-Number values to
> functions that return anything but xint::integers.
>

There are at least 2 other possibilities:
1) Prevent it from compiling in the first place
2) Block until you have the required entropy

Or the I'm-not-even-counting-it option of having the function default
to an insecure RNG like Mersenne Twister...