Re: Fixed-Point Decimal Library

From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2001-10-31 12:55:31

I just looked at the Boost messages on the Yahoogroups Web site;
and I see that Damien had some interesting points.

>
> I notice the use of throw() specifications in inlined functions
>

Only in code that relates to specializing std::numeric_limits<>.
The Standard specifies empty exception specifications for all
of that class' member functions; and my hope is that, by adding
"throw()" to everything that the specialization uses, the
compiler will be able to trace back and optimize away all the
exception checking code.

>
> By the way, I noticed this in the documentation:
>
> "Efficiency is not an important consideration for this library
> because the author believes that financial applications tend
> to spend most of their time doing I/O. More important by far
> is a convenient interface."
>
> I would disagree with this.  Many financial applications
> would fall into this category, unfortunately, the ones
> I write don't :).  That is, server-side applications
> processing real-time financial data (which can spike to
> very large loads).  Efficiency is my #1 concern.
>

If you have any suggestions about how I can make the code
more efficient, I'd be glad to hear them.  I'd also want
to hear that you've profiled the code and know where the
bottlenecks are.

>
> I also notice you have defined operator++ and operator--.
> I am not sure whether these are appropriate for a fixed
> point type.
>

They're defined for floating-point types; and they add or
subtract 1.0, which doesn't seem surprising to me.

But having made that argument, I now wonder whether I
should have the % operators, which are _not_ defined
for the floating-point types.  Should I instead have
functions analagous to fmod() and modf() from <cmath>?

>
> You also defined operator++() and operator++(int)
> independently of each other, and you also have a lot of
> boilerplate operator code further down in decimal.hpp.
> Using boost::operators might assist in readability in
> cases like this.
>

Working...

>
> I like the ability to customize the rounding, but I
> would suggest that ... a better approach would be
> to use add a policy to the class.  This way one
> can easily have different fixed point objects with
> different rounding policies, which is important
> (to me at any rate!).
>

Do you want the rounding mode bound to the operand
rather than to the operator?

There's one other question that I'd like to pose
to the group.  I'm having second thoughts about
the money<> class.  It seems like users should be
able to write the expression

  a * b / c

but they can't if a, b and c are money<> instances;
and if I fix this in general, I'd need both money-
squared and reciprocal-money classes.  Should I
do that work or just trash the money<> class?
(If the latter, I could write I/O manipulators
that select numpunct<>, money_put<>/money_get<>
or moneypunct<> facets.  I need to do that anyway
for moneypunct<> so that users can select either
ios_base::precision() or moneypunct<>::frac_digits()
digits to the right of the decimal point as stated
at the end of the current HTML document.)

Thanks for the input,

--Bill Seymour