Re: [boost] Fixed-Point Decimal Library

From: Fisher; Damien Kaine (dfisher_at_[hidden])
Date: 2001-10-12 21:31:52

I can't believe you could write something like that using MSVC 5.0.  I am
very impressed :).  (Someone buy this guy an upgrade :) )

I notice the use of throw() specifications in inlined functions - these
are evil aren't they? (in terms of compiler optimizations)  I never really
understood why they were included in the standard (hopefully someone can
explain this?).  I'm probably not the best person to comment on this
aspect, but:

http://www.boost.org/more/lib_guide.htm#Exception-specification

seems to support this.

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.

I also notice you have defined operator++ and operator--.  I am not sure
whether these are appropriate for a fixed point type.  The way you have
implemented it:

boost::decimal<3>(0.1) d; // stores 0.1
d++;
// d now holds 0.101

This is a totally subjective matter of course, but I think some people
might think that d would end up holding 1.1.  I think it would be best to
just get rid of ++ and --.

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.  In fact, I think you could find decimal.hpp would be
significantly smaller if you used them.

These are small points however.  I think the library overall is neat.  I
can't really comment on the locale/iostreams as I don't have much idea
about that sort of thing.  I like the ability to customize the rounding,
but I would suggest that instead of using a preprocessor macro
BOOST_DEFAULT_ROUNDING_MODE in all the operators to handle rounding, 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!).

That's about all I can comment on after looking at it for a few minutes,
and I haven't even tried to compile it yet.  Which means most of what I've
said is probably wrong :).  The library looks very useful though, but I
will have to look at it further to see if it is efficient enough for my
needs.

Damien