[boost] Re: Any interest in a decimal and money class?

From: Daniel Frey (d.frey_at_[hidden])
Date: 2005-01-09 06:06:50

Martin wrote:
>>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?

ctor. Either directly:

   money m( 42, "EUR" );

or indirectly through a predefined currency to prevent typos and make it 
even more efficient:

   const currency EUR( "EUR" ) // Only once in some global project header

   money m( 42, EUR );

additionally, you can use:

   decimal d = m.amount(); // getter
   m.amount( d ); // setter

   currency c = m.currency(); // getter
   m.currency( c ); // setter

to access the parts.

> 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.

The point is that when I want to use a new underlying type for 
calculations, I have a single point of customization, about 100-200 
lines. The specialization of decimal_traits<T> for that type T and the 
typedef for decimal. I don't have to touch the 300.000+ lines of code 
that use it. What do you prefer?

> 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.

The folks in my company are basically in favor of boost, so I hope they 
allow me to take some of the stuff here. Even if they don't allow it, I 
can still take my knowledge of general programming techniques (where 
lots of them come from boost!) and implement the classes from scratch. 
It'll just take a bit longer.

To combine our work, I think it's best to separate it. As I said, 
decimal64 might be a candidate for basic_decimal<T>'s T. As I write 
this, I realize that I can describe basic_decimal as a helper for 
basic_money<T> (and the application as a whole) to decouple from T's 
interface. Maybe this helps to understand why basic_decimal is there. 
I'll ask about using the company's basic_decimal/basic_money/currency as 
a template for the boost implementation tomorrow and we can then discuss 
it independently of decimal64.

I think it's most useful if you work on decimal64 independently of 
money/currency issues. Make it a cool new float-point type and 
basic_decimal will be able to use it :)

Another benefit of the indirection through basic_decimal<T>: FWIW, there 
is one thing that my classes don't do right now and which I always 
dreamed of: "Correct" epsilon handling. Like

operator== respects a given epsilon
native_less(a,b) like the current operator< for the underlying type

a!=b -> !(a==b)
a<b -> native_less(a,b) && a!=b
a>b -> native_less(b,a) && a!=b
a<=b -> native_less(a,b) || a==b
a>=b -> native_less(b,a) || a==b

But we could encapsulate that in the decimal_traits<T>, too, so you can 
switch your application from no epsilon to different epsilons in a 
single place. Wouldn't that be cool? :o)

Regards, Daniel