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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-31 20:06:11

-----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-----