-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/30/2010 07:15 AM, Stewart, Robert wrote:
Existing code may rely on getting a NaN, or may rely on *not* getting a NaN. Policies allow users to decide.
Exactly what I was intending with the exception-blocking mechanism.
Your approach involves runtime cost, I think. Policies allow altering the implementation, at compile time.
Which isn't necessarily the best way to do it, and certainly isn't the only one. There is effectively zero runtime cost for XInt's exception-blocking mechanism, since the code used for it is only evaluated when an exception needs to be thrown. Perhaps you're thinking of the earlier comment that having a Not-a-Number value in the library involves some runtime cost. That's true, but the cost is so minimal (one comparison to zero for each integer-type parameter to a function) as to be unnoticeable -- a handful of clock cycles per function in the very worst case. If that's a problem, I can reduce it even further, but I don't expect anyone will be able to show that it is.
How does one mix code wanting exceptions with code not wanting them? With policies, the two types differ, but can be designed for interoperability.
And with XInt's exception-blocking, nothing differs except the behavior. - -- 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/ iEYEARECAAYFAkuyBNAACgkQp9x9jeZ9/wSpaACcCPYXh15ZMbGx6eU1VxTH4tLj pUAAnjbUGY1mGiB621B3it3GpnxM4DOy =Dra8 -----END PGP SIGNATURE-----