Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk