[boost] Fixed-decimal partial review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-07-19 11:16:28

Please forgive me for only commenting on a few issues; I'd hoped to write a 
full review, but the time just isn't there. Sorry if the issues have 
already come up.

* 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