Re: [boost] Fixed-Point Decimal Interface

From: Bill Seymour (bsey_at_[hidden])
Date: 2001-05-11 09:03:21

I think the discussion is going astray.  What I'm proposing
is not intended for numerical applications.  Folk who do
numerics already have well-understood tools.

What I want to write is a type that deals with amounts of
_currency_; and I want to keep it simple.  I don't want to
generalize it like std::string to have something for everyone.

Some ideas from John Skaller:
>
>  increment and decrement are undefined
>

What's undefined about adding and subtracting one?  Sure,
the operation could overflow if the type has no integral
part; but by that argument, addition and subtraction are
undefined in general.

>
> OPINION: All the non-assignment operations should be functions,
> NOT members. NEVER use members for functional operations.
>

I note that Fernando Cacciola agrees.  What's the reason?

>
> OPINION: REMOVE the money class. This should be proposed
> separately, and the discussion should be separate.
>

That's actually _the_ class that's important, IMO.  The
decimal class is there principally because it doesn't
make sense to multiply money by money.  (This was inspired
by the SI Units work.)

>
> OPINION: REMOVE the constructor taking the integral and
> fractional parts. It just confuses things.
>

What's confusing about it?  And how would you initialize
a decimal object with a non-integral value?  The ctor that
takes a const char* (or std::string) is an option, but it's
computationally expensive (as George Heintzelman pointed out);
and the ctor that takes a double is inexact.

>
> OPINION: Provide a default constructor, which guarrantees
> initial value 0.
>

Already done if we don't remove the two-argument ctor above.
(The default arguments allow it to serve also as a default ctor
and as implicit conversion from an integer value.)

>
> [The decimal] class intends solely to use 'long int' to do
> fixed point calculations, ...
>

No, it doesn't.  A 64-bit integer is one possible internal
representation; BCD is another.  Indeed, I plan to try it
both ways; but at this point, I'm still trying to get the
public interface right.

--Bill Seymour