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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2010-03-31 11:59:25

Chad Nelson wrote:
> On 03/30/2010 01:38 PM, Jeffrey Hellrung wrote:
> 
>>> That it acts like a pointer but isn't one. Less experienced developers
>>> often find even pointer syntax hard to master, and unfortunately, they
>>> are the majority of programmers. I was trying to make it as easy as
>>> possible for anyone, no matter what their level of experience, to use.
>> I can't buy this, given that pointer syntax is so prevalent in C++
>> (pointers, iterator, smart pointers). [...]
> 
> I wish I could avoid buying it. My previous company wrote tools for
> developers, and I had to deal with a lot of customers who couldn't
> program their way out of a wet paper bag. Including ones that used C++,
> but probably shouldn't have.
> 
>> IMHO, any developer should be fine with a Boost.Optional return value
>> (as long as you reference the documentation, and optionally provide a
>> brief 2-sentence summary of Boost.Optional), and he/she might even
>> appreciate the opportunity to learn the utility of another Boost
>> library. 
> 
> 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.

>> This would remove the necessity of this special NaN value, noticeably
>> simplifying the interface, implementation, and reasoning of this
>> library.
>>
>> 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?

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.

- Jeff