|
Boost : |
From: Ilya Buchkin (elias_at_[hidden])
Date: 2003-07-19 15:39:38
"Bill Seymour" <bill-at-the-office_at_[hidden]> wrote in message
news:3F1940AA.6EB72EC3_at_pobox.com...
> 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?
Bill,
I am not sure why you did not include in the list of options the
suggestion I made *twice* in previous threads - have TWO classes:
1. one with declared fixed scale, template-based.
2. another with variable scale, non-template.
It would solve all problems you enumerated:
a. Each of them would be OK to use in std::containers.
b. The second class would allow for collections of different scales.
c. Containers with objects of each of these classes would be sortable
correctly.
d. No need to specialize std::swap() and other standard algorithms.
As an extra benefit, no magic would have to be involved.
If you have reason(s) to dislike this suggestion, IMHO it would be
fair to state it in the forum. I would not insist on attention to this
particular suggestion, but you seem to be seriously discussing
options like #2 (i.e. "solve" problem at expense of future users)
and #3 (no comment, as no one has a way of knowing
what you mean by that).
Speaking about your option #3: if you simply need more time
to sort issues out, you should probably just say that,
and extend (or re-schedule) the Formal Review.
Regards,
Ilya Buchkin
MetaCommunications Engineering
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk