In our applications, we can't predict the currency of a money variable at compile-time, and the overhead of the currencies is acceptable due to the very lean implementation (only 4 bytes, single comparison for checks).
Yes, that was one of the reasons I removed the currencyid from the type but I didn't find any good way to specify the currency for individual objects. Do you have it as a constructor argument or is it a property?
The basic_decimal<T>-class is just a generic float point interface. It defines what can be done, not how it's done. Example: Depending on T, some classes have member functions where others have free functions. It's round(x,2) vs. x.round(2).
Sorry but I don't understand what you gain from that approach. If I understand correctly you will need a specialization of basic_decimal for each type T. A specialization has no correlation to the template (except the name) so you will not get any compile errors if the specialization basic_decimal<double> has a completly different interface than basic_decimal<int>.
syntax. Actually, I have a decimal_traits<T>-class which is specialized for all T's that can be used in our applications with basic_decimal and basic_money.
Ok, basic_decimal only forwards calls to the decimal_traits but that still doesn't change the fact that you need specializations for each type. Why is it better to have decimal_traits<decimal64> & decimal_traits<decimalBCD> than to implement decimal64 & decimalBCD to have the same interface? I can understand it if there are some types that don't need specialization of decimal_traits. Writing basic_money<double> is very confusing to me since it gives me no hint on what I get. If I write basic_money<decimalDouble> I understand that I can look in the documentation for deicmalDouble.
Only if decimal64 and decimalBCD have the same interface. And you can't replace it with double or RWDecimal<RWMP3Int>, because their interfaces differ.
In your implementation decimal_traits<decimal64> and decimal_traits<decimalBCD> need to have the same interface so what's the difference. Don't get me wrong here. I am usually in favour of traits classes but in this case I don't see the point. Going forward. Can we combine our work? I like your run-time currency and maybe you can convince me about the traits but I assume your solution is part of your work so it can't be used in boost.