I've been thinking about the related issues of whether decimal should be a template and whether the scale should be immutable.
First, I'm adamant that the user should be able to write
dollars = foo;
without magically losing pennies or gaining mils; and I don't think the user should have to type something like
dollars.assign_without_changing_frac_digits(foo);
as a workaround to get that behavior.
Given that, then as Daryle has correctly pointed out, standard library sequence collections of decimals, and mutating algorithms that work on sequences of decimals, don't work right unless all objects in the sequence have the same scale. This issue of "working right" must be addressed before we worry about efficiency or the size of the objects.
1. The scale could be part of the type (decimal becomes a class template).
2. A warning could be put in the documentation that says that storing decimals of different scales in the standard collections yields undefined behavior.
3. I could try to work some other kind of magic.
The main difference I see between 1 and 2 is whether it's possible for the user to make the mistake. In neither can we have collections of different scales; but I now think that ought to be allowed if there's some way I can make it work. (Note, for example, that with either of the first two solutions, 1, 1.2 and 1.23 can't be sorted!) So I'd like to try 3, at least as a mind experiment, before deciding on 1 or 2.
Note that copy construction works correctly; it's just assignment that has the perverse behavior.
Let's say I specialize std::swap() to swap scale as well as value, and then specialize other standard algorithms to use swap where they might otherwise use assignment. Have I done enough?
I warned against making the users having to write custom versions of all STL. I didn't mean the solution to be for you to do all the customizing yourself! That's a ridiculous amount of busy-work. It also fails on (at least) two counts:
1. It fails when the user want to make their own STL-like algorithm, especially if they don't know they have to re-work the algorithm for the decimal family.
2. Doesn't help at all with the STL containers, which you don't have access to how their assignment/copying is done.
Combining scales isn't as hopeless as you make it sound. When objects of different scales are combined, you round to the less-precise scale. Why don't you go up to the maximum scale instead.
1.3 $ 2.98
Instead of chopping the above to one fractional digit, go to the max. That would be 2 for addition and 3 for multiplication. You'll add or multiply the significands exactly and return the fully-precise result. Of course, this assumes each number represents that exact value. (You treat them like exact rationals and not a smear of values like floating-point). And this has to be for the non-assignment forms, since the scale can change. Some rounding would have to occur for the combo-assignment forms.
Daryle
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
