Boost logo

Boost :

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

Thanks to Bill Seymour for his efforts!


Boost list run by bdawes at, gregod at, cpdaniel at, john at