-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/29/2010 12:57 AM, Scott McMurray wrote:
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.
When it's possible that you've gotten a Not-a-Number value. As I've said before, those can only be returned by a small number of functions, even if you're blocking exceptions.
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.
An unavoidable consequence of having a Not-a-Number value. Fortunately, the check is extremely fast.
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.
It might improve individual checks, but there would have to be a lot more of them. And the overflow exception should be extremely rare on modern systems, unless you're using a staggering number of unbelievably large numbers.
(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.)
Now that's a valid argument, and it might be strong enough to outweigh my logical-return-values complaint. I don't have a strong objection to making the not_a_number exception blockable -- give me a reasonably non-contrived example where having it would make code more readable, and I'll find a way to make it happen.
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
Not acceptable. I want it to be easily portable, which means it has to compile even if the machine doesn't support any cryptographically-secure random number generator that the library recognizes. The developer using it can always plug in a generator that gets entropy from something the library doesn't know about, like an Internet site dedicated to that, after all -- they do exist.
2) Block until you have the required entropy
XInt isn't in the business of providing random numbers, the random number system in it is there solely for the random prime number generation facility. Gathering entropy isn't part of its job description. That may not be obvious from the version in the Boost Vault at present, but it will be with the next iteration.
Or the I'm-not-even-counting-it option of having the function default to an insecure RNG like Mersenne Twister...
Which is exactly what the library did in the current Vault version. The as-yet-unreleased version throws an exception, because that is an exceptional circumstance, and one that the developer must not ignore. - -- 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/ iEYEARECAAYFAkuwPTUACgkQp9x9jeZ9/wQk1gCfecl2Gwv0clT9hDf6kBnNALBQ 1hwAoNnZdaDgUWp7alOMI/CBvAb5lyaj =icpx -----END PGP SIGNATURE-----