Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk