I don't think the point is that a Boost decimal type has to be compatible with the upcoming decimal TR, but that the Boost decimal type could use the TR types or the Rogue Wave decimal types or whatever as the underlying type.
Well, I got another view. My class implements a decimal type and so does Rogue Wave and TR, all with different approaches. When you select a decimal type you look at the properties of each type and make your choice based on your requirements. If you try to fit everything into one type you would either have to limit yourself to the least common functionality or add workarounds (maybe very inefficient) for not supported functionality of the underlying type. Money is a different matter. There I agree that the the type should allow you to use different underlying decimal (or maybe even binary) types.
Since my solution (and your library roadmap)
is fixed precision and the standard will be floating point (+fixed via encoding) it is not possible.
The folks pushing the decimal TR have been claiming that the integer subset is robust enough to handle the usual integer operations. Presumably it would include everything needed to implement fixed-point.
That is my view as well and that is why I created my decimal64 type. Do you mean that we don't need a fixed decimal type since everyone can implement it themselves using integers?
(And as I said in another post I don't actually see the need for decimal floating point. It solves a couple of theoretical cases where you can use == to compare values but are there any real applications for it?)
Some very experienced people believe there is. While I once implemented a lot of business calculations using decimal floating-point, I never had the luxury of having hardware with both binary and decimal floating-point, so don't know if binary would have been more useful than decimal. But since sometimes we were implementing tax related algorithms specified by law as decimal calculations, it was convenient to work in fp-decimal.
Laws are different everywhere ofcourse but the ones I have seen specify the number of decimals to use in a calculation and not the number of digits. Did you use a fp-decimal type where you could limit the size of the mantissa?