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

From: Martin (adrianm_at_[hidden])
Date: 2005-01-11 02:51:26

Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
> I was at OOPSLA and I think everyone needs to keep in mind that not having a
> vote at OOPSLA does not imply there is no interest in a library or category. 
> Obviously we had a very small subsection of boosters to sample and their
> priorities might not match with many other boosters priorities.  Also, the
> fact that it was discussed and on the list means that there is at least some
> interest.
> 
> Anyway, I'm interested in these libraries even though I don't have an app 
that
> would use this right this minute.  Here's my reasoning.  To my way of 
thinking
> there is tremendous leverage to be gained in the use of well-tested value
> types in codification of interfaces, hiding of complex domain rules, and
> overall simplification of code.  Kevlin Henney has written some articles on
> this (http://www.two-sdg.demon.co.uk/curbralan/papers.html).  So on my
> 'library roadmap' (wiki page: http://tinyurl.com/6v5vx) I have a category
> called 'value types' where I have a list of these libraries I'd like to see 
in
> boost (your's is one of them 

I understand what you are saying but the comments in this thread (except the 
discussion Daniel and I have about money implementation) seem to be that there 
is no need for a decimal type in boost unless it is compatible with the 
upcoming standard. Since my solution (and your library roadmap) is fixed 
precision and the standard will be floating point (+fixed via encoding) it is 
not possible.
(And as I said in another post I don't actually see the need for decimal 
floating point. It solves a couple of theoretical cases where you can use == 
to compare values but are there any real applications for it?)

Money and currency isn't mentioned on your library roadmap and there are no 
comments here (except from Daniel and he already got a well proven 
money/currency class that he will make available to boost).

Maybe I should concentrate on my locale library instead and add the missing 
locale_cast functions (e.g. locale::to_string(mydouble, number_format
(',','.','3"))