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