|
Boost : |
From: Martin (adrianm_at_[hidden])
Date: 2005-01-08 16:22:39
Daniel Frey <d.frey <at> gmx.de> writes:
>
> I strongly suggest to use a currency, as otherwise you'll likely miss
> the intended audience's requirements.
I actually had this implemented at start but removed it at one point. I
implemented it like this:
template <class DecimalT, int CurrencyId = 0>
class money_base ...
You created different currencies by doing
typedef money_base<decimal64, 1> USD;
typedef money_base<decimal64, 2> EUR;
If I needed values without currency I just used the decimal type.
decimal exchangerate(usd.as_decimal(5) / eur.as_decimal(), 5); // 5 decimals
(Your debtor example would probably need to use boost.any with my solution)
Your run-time currency type is an interesting approach.
> > Integers works as both money and decimal so Money*2 and Money+1 is always
> > allowed.
>
> money*int is OK, money+int is not. And FWIW, I never saw any of my
> colleagues complain about money+int not compiling. If the compiler
> happens to catch it, it usually means that it saved them from a having bug!
And I was afraid my interface was to strict. Thanks.
> The application can/should then create central typedefs:
>
> typedef basic_decimal<long double> decimal;
> typedef basic_money<decimal::value_type> money;
Not sure I understand. The implementation of decimal arithmetic will be very
different depending on the type (e.g. double, int, BCD strings) so I don't see
how it can all fit into a basic_decimal. It is fine as an ABC but does it
really add anything (except virtual calls).
Also shouldn't basic_money use the decimal type instead of the decimal type's
internal representation (i.e. basic_money<decimal>)
> That way, you can switch your complete application for different
> underlying types that are used for the real calculations easily.
You can do the same with my solution but it would look like this:
typedef money_base<decimal64> money;
or
typedef money_base<decimalBCD> money;
typedef money::decimal_type decimal;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk