Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at