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