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
would use this right this minute. Here's my reasoning. To my way of
Jeff Garland <jeff <at> crystalclearsoftware.com> writes: that 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"))