-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2010 11:59 AM, Jeffrey Hellrung wrote:
Should, definitely. Would... well, we can hope. :-) That wouldn't necessarily stop them from using C++, or Boost, though -- that's why I wanted to make it as simple as possible.
If all Boost libraries catered to the lowest common denominator "developer"...well...Boost.MPL and Boost.Fusion might be the first to go... ;) In all seriousness, though, usability is certainly important, but you have to draw the line somewhere. I think if you're submitting your library for review to Boost, you should embrace what Boost makes available to you.
While I agree with the theory, I'd still like to avoid it if at all possible. And since I only need it for two functions, which (as has been proven to me) ;-) can equally well return zero for invalid values, there's no particular need for it.
Sorry to be such a bear; I'm only trying to improve things.
And I'm sorry if I seem to be a stubborn mule about it too. I'm not trying to be, no matter how it might look. :-) I just need a strong enough reason to change the design. I think Scott McMurray just provided such a reason; please see my reply to him for my proposed solution.
Yes: Separate the NaN stuff from the rest of the fundamental operations (arithmetic operations, etc.), and, if you're really tied to it, add it back in a wrapper class. However, I still maintain that this NaN framework, as is, is not fundamental to any operation, and it's only motivation is to make the return values of no-more-than TWO crytographic-specific functions "convenient" for developers who have difficulty with pointer syntax (even though, for those developers who have no problem with pointer syntax (i.e. me) it's less convenient). Am I exaggerating?
Only in that it's also used for the exception-blocking system. If those two functions were the *only* reason for it, I'd have stuck with Boost.Optional for them.
An NaN framework which I actually consider useful would be one which is always signaling (i.e., throwing, even upon creation), or always quiet (NaNs are propagated), or even runtime configurable with your exception blocking idiom (which I think is useful). A "half-signaling" NaN (quietly manufactured but noisy when touched) seems to me a near-useless middle ground.
Also, you shouldn't be looking for a "strong reason to change the design". Look for the best design, regardless of what the current design is.
Ah, but I already *had* a very good design, in my opinion. I needed a strong enough argument to convince me that there was a better one. :-) Which Scott McMurray provided, by pointing out that it would simplify the job of writing other libraries that use XInt. - -- 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/ iEYEARECAAYFAkuz424ACgkQp9x9jeZ9/wSAJwCg3vQXIN83OAYl2k1GPpVviooO eL0AoKkj7t/o0X2+JrMtM0H4iLHmvvJJ =pzzE -----END PGP SIGNATURE-----