Re: [boost] Re: Fixed-Point Decimal Library

From: Fisher; Damien Kaine (dfisher_at_[hidden])
Date: 2001-11-02 01:36:49

On Wed, 31 Oct 2001, Bill Seymour wrote:

> > 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.

Ok.

> > "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.

Sure.  I wasn't suggesting there wasn't anything inefficient there, just
that I think efficiency should be a concern for a class which represents
such a fundamental type.  I will look at the code in detail soon and get
back to you if I have any concerns.

By the way, when I say "efficiency" I don't just mean time-wise, but also
space-wise.  Eg the objects should be as small as possible.  When you have
an OODB full of the critters 4 bytes makes a big difference.

> > 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.

Yeah, I think I was a bit whacked out when I made that comment :).

> 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>?

Hmmm...that really is a matter of taste IMHO.  I'm not really sure how
often I would use operator % on fixed point types personally, so I would
be inclined to go for the more verbose function names.  But that's not a
very good argument :).

> > 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?

My comments were centered around this:

#ifndef BOOST_DEFAULT_ROUNDING_MODE
#define BOOST_DEFAULT_ROUNDING_MODE bankers_round
#endif

This is then used when multiplying, adding, etc.  Doesn't this
potentially violate the ODR?

One solution is to make it a policy:

template<class RoundingPolicy, int Prec = 0>
class decimal
{
   // do that crazy decimal thing
}

Of course, this has the side-effect that the rounding policy is then bound
into the type.  This makes sense to me - how else will you get operator *,
operator / etc working properly?  You can also provide mul, div routines
(I think they are already there) which allow the user to specify a
different rounding policy.