Martin wrote: [...]
--- The discussion on decimal types, including the review of a decimal library two years ago, indicates that to be accepted in boost a solution should allow some (or all 4) types to be used as base in something like "basic_decimal<>".
So lets discuss how a basic_decimal interface should look like. The main problem I see lies in the construction:
Type 1 & 2: basic_decimal(value) Type 3: basic_decimal(value, precision) Type 4: basic_decimal(value, precision, rounding_mode)
Rounding is not a big problem since a sensible default can be used but how to solve the precision? Creating a decimal type 3 or 4 without specifying a precision is bad since there is no good value to use as default. Precision also has a different meaning for a decimal type 1 & 2 (i.e. only affects extractions, not operations).
IMO any kind of automatic rounding and precision should not be part of a basic_decimal type at all! The behaviour of basic_decimal should stick to the decimal proposal of Mike Cowlishaw and he explains very well in his FAQ section why it's not a good idea to have normalized decimal arithmetic: http://www2.hursley.ibm.com/decimal/decifaq.html However, it could be possible to provide some add on, maybe controlled by a policy, that also handles rounding, precision and normalization. [...]
The other members of basic_decimal isn't very complicated: A full set of arithmetic operations (+,-,*,/,%) and assignment must be included. Operations should work on integers and maybe also string literals. For decimal type 1 & 2 it makes sense to also allow operations on doubles. Assignment should work on integers, string literals and double for all types.
These are the operations of IEEE 754R; they should be at least supported in some way. * abs * add and subtract * compare * divide * divide-integer * max * min * minus and plus * multiply * normalize * quantize * remainder * remainder-near * round-to-integral-value * same-quantum * square-root * power And don't forget relational operators.... Stefan