From: Seymour, William A - St Louis, MO (WSEYMOUR_at_[hidden])
Date: 2002-09-11 12:24:33
> From: Fernando Cacciola [mailto:fcacciola_at_[hidden]]
> Sent: Wednesday, September 11, 2002 7:44 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Fixed point decimal
> Hi Bill,
> I've just read this whole thread, and at some point you
> mentioned that could could go back to a template version;
> I would really like that.
> A few months ago I needed a fixed-point decimal class to
> perform some geometric computations.
Do you need a fixed-point decimal type or a fixed-point
> The first thing I tried was your class, ...
Oh, dear! It's still at the "What's your interest?" stage
(and there hasn't been much); and it hasn't really been tested.
I hope I wasn't too badly embarrassed by your trials. 8-)
> If you could turn the fixed decimal class into a template so
> I can use it with an arbitrary length integer class it will
> be just what I need.
That would move a lot of computationally expensive code into
the header file.
Also, doing what amounts to std::div() on any arbitrary type
is likely to be inefficient. (I think I need to do something
like div() because the / operator's direction of truncation,
and the sign of the % operator's result, are implementation-
defined for negative values in C; and I don't find any normative
text in the C++ standard that changes that. If somebody can
point me to such text, /please do/.) OTOH, I'm already doing
an inefficient div if my integer type is other than int or long;
so maybe that's not a problem.
> BTW; I need a compile-time-fixed number of decimals, and the
> same for all decimal values. If you can do something to improve
> performance for those cases it would be great.
Are you talking about the time it takes to calculate the
representation of unity given the scale? The only compile-
time way to do that, AFAIK, is to use a recursive template;
but the result wouldn't fit in an enum in general; and I
don't know any other way to store the result portably.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk