On 28 March 2010 23:56, Chad Nelson <chad.thecomfychair@gmail.com> 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...