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

From: Daniel Frey (d.frey_at_[hidden])
Date: 2005-01-11 18:00:23

Rob Stewart wrote:
> From: Martin <adrianm_at_[hidden]>
> 
>>>Your decimal64 is both an interface *and* an implementation. I just 
>>>suggest to separate it. Let basic_decimal take care of the interface, 
>>>while decimal64 takes care of the implementation.
>>
>>I can agree that the interface could be formally specified as a basic_decimal 
>>but still don't understand the benefits of a decimal_traits vs a class that 
>>implements the basic_decimal interface.

OK, ask Roguewave to modify their classes to implement the basic_decimal 
interface. They won't do that, right? So what will you do now? Write a 
wrapper? OK, but what is the easiest way to write a wrapper? I don't 
want to limit the T's to types that conform to my interface. So I need 
wrappers. So, IMHO, the question is how to make it safe and easy to 
create such wrappers (or adaptors)?

> basic_decimal can utilize fundamental operations from the traits
> class to provide the full interface.  Put another way, the traits
> class needn't provide the entire interface that basic_decimal
> provides, so adapting a new type to fulfill the basic_decimal
> interface is easier.  (That's theoretical, of course.  I haven't
> any idea how much logic Daniel's basic_decimal implements beyond
> that provided by his traits class.)

I think this is generally correct, although there were more reasons for 
a basic_decimal class. It allows me to control the interactions with 
basic_money. I can declare operators like this:

template< typename T >
basic_money<T> operator*(basic_money<T> lhs, basic_decimal<T> rhs)

which is better than allowing basic_money<T> * T because I know more 
about basic_decimal<T> than about T. Maybe this is influenced by the bad 
design of some T's, but that's the real world. :( So this argument for 
basic_decimal<T> might also be seen as nannyism, but to me, basic_money 
and basic_decimal belong together because it's the only way I can make 
basic_money safe. having a decimal_traits class and writing mappings to 
some type T is a consequence.

And having written basic_decimal<T> myself, I know exactly all ctors, 
conversions, etc. provided, no chance for T to create a SNAFU but adding 
a ctor which takes a double or something stupid like that. The 
decimal_traits are not only a helper to write a mapper to some T faster, 
they also help to make it safer, because their interface is more 
explicit and more restricted than that of a generally useful interface 
of some T.

Regards, Daniel