[boost] Re: Fixed-Point Decimal Proposal

From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2002-03-11 11:48:17

/Michel wrote:
>
> ... i would expect some handling of overflow conditions ...
>

I agree; but I don't know of any way to detect overflow
without causing it; and then it's too late.

>
> And it would be good to have the integer type as template
> argument ...
>

Perhaps when compilers get export working.  For now,
I'd rather stick the guts of the arithmetic in a .cpp
file, which means that I have to know the internal type
at coding time.  If I stick everything in the header,
it grows from about 32k to about 48k.

>
> Maybe the name should be changed to fixed_decimal.
>

No objection.  I'll change the name unless somebody else
tells me not to.

Damien wrote:
>
> ... if [using a macro to select the default rounding mode]
> hasn't changed since Bill's last submission, I have big
> problems with this too.  It seems to me that using a macro
> could very easily lead to violations of the ODR.
>

Yes, and it's documented as such.

The alternative, it seems, would be to make it a modifiable
singleton, sort of like the current locale.  Would that
be worth doing?  (It raises issues of thread safety.)

Jeff wrote:
>
> What I was really should of asked for is few lines of code
> that show what a user can.  Some basics like:
>
>   decimal<2> foo(100); //construct from int
>   foo++;  //foo == 101?
>   decimal<2> bar(10.2); //construct from double
>   decimal<4> foobar = foo * bar; //result is ?
>   foobar =+ 10.1; //add a double?
>   foobar = foo + (bar * foo); //is this allowed ...?
>   if (foo >= bar) {}
>   double barbar = to_double(bar);
>   std::cout << foobar << std::endl;
>

Yes, I should have some examples early in the documentation.
I'll work on that.

>
> From what I understand the advantage of the current design
> is that I can mix and match operations on types with different
> rounding modes.
>

Well, in the current design, types don't have rounding modes;
but, yes, the idea is to let users do arithmetic with a variety
of rounding modes, including user-defined rounding modes.

>
> Mostly I would want one rounding policy for my 'money' class
> arithmetic and I want to set that at compile time and forget it.
> But I might also have a 'stock price class' that uses a different
> rounding policy.  Unless I misunderstand, these 2 classes
> currently can't have different rounding policies in the same
> application by default.
>

Well, they can't have rounding policies at all; but, yes,
there can be only one default.

>
> Instead with one I will have to be explicit because of the
> default rounding mode.
>

I would have said that with one you can be _implicit_ because
of the default.  In the absence of a default, you'd have to be
explicit all the time.  8-)

[re the to_string function]
>
> I was thinking of a free function ...
>

Agreed...I was typing a little too fast.  (My knee-jerk
reaction is to think in terms of member functions.  I need
to work on that.)

--Bill Seymour