* I'm unhappy with the use of int for passing values to several functions.
This seems like a recipe for portability problems, when users port code to systems where int is only 16 bits.
I gather from the commentary that using int_type causes overload resolution problems with double. (I'd prefer "value_type" as the name, rather than "int_type", typedef'ed to boost::intmax_t.)
Two possibilities:
-- use enable_if<> to take double out of the overload set. (I don't know if that will really work; I've read about enable_if but haven't used it in practice yet.)
-- Eliminate the double overloads. The intended users are unlikely to be fully aware of all the issues surrounding floating point anyhow, and thus my shoot themselves in the foot.
* In the docs, you emphasize financial and money related applications. Years ago I worked on some general business applications involving liquid inventories dealing in tank dimensions, gallons, coefficients of expansion, and all sorts of other non-money related data. Fixed-point arithmetic was essential for those general business applications even though they aren't strictly speaking financial or money related. (The reasons floating point won't do is the legal and business need mandated others, including government regulators, to be able to repeat the exact computation, and produce the exact answer.)
* My guess is your intent is to supply a full set of arithmetic operations. It is really easy to forget something (that's the point of the boost operators header). If that is your intent, you might say so in the docs to make it clear any omissions are unintentional.
* I vote for namespace boost::numeric.
* I'd really like to see more formal material in the function descriptions, including preconditions, throws, and the other usual formal specifications. The current prose descriptions are great for quickly grasping what the functions are supposed to do overall, but don't nail down the detail specifications very exactly.
* As it stands now, it isn't clear at a quick reading what constitutes error conditions and how they are handled. The applications I have in mind can't tolerate silent errors, so I hope there is a really serious error detection and notification strategy.
* The rounding mode look like great solution to a serious problem.
With the caveat that I've only spent an hour looking at the docs, and have only skim read other's comments, I (weakly) vote "yes" to accept the library.
Thanks to Bill Seymour for his efforts!
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
