|
Boost : |
From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2003-07-18 12:42:53
Paul Bristow has convinced me that I need longer, clearer names
for the I/O manipulators. First draft:
pure_number
national_currency
international_currency
number_stream_frac_digits
number_decimal_frac_digits
money_stream_frac_digits
money_decimal_frac_digits
money_locale_frac_digits
I don't like this yet. Suggestions for improvement are welcome.
I'll also take the suggestion to put frac_digits() in the public
interface and "fraction digits" in the text of the documentation.
Paul:
>
> MSVC IDE is command-line hostile - could macros could provide
> suitable examples of platform-specific locale arguments?
>
Well, it seems like you'll need to create a "console application"
in any event because any test program I write will have a main(),
will write to cout and/or cerr, and maybe read from cin. I have
no objection to allowing the locale to be specified by a macro;
but can't you just run the test program from a DOS prompt?
Daryle Walker and Ilya Buchkin are raising some important issues
that probably go away if the scale is part of the type. I'll
address that in another message; but here are some easier answers:
Daryle suggests operations that increment and decrement by 1 ULP;
and I think that's a good idea. The names I like are next_value()
and previous_value(); and I'll probably include versions with
dummy int arguments to parallel the built-in postfix operators.
Daryle also suggests opening up the internal representation
with accessors. How about:
int_type raw_value() const; // value in ULPs
int_type unity_value() const; // representation of 1.0
int frac_digits() const; // formerly scale()
Ilya seems to be giving me mutually contradictory requirements.
On the one hand, he wants objects with a footprint of no more
than eight bytes; and he correctly points out that that's
technically feasible if the scale is a template parameter.
Oh the other hand; he seems to want to be able to do any
arbitrary calculation without rounding which, in general,
would require objects of infinite precision. (It's not
my intention to put up a straw man to knock down, so please
correct me if I misunderstand.) I'm afraid I'll have to
disappoint him on the second count. I haven't finally
decided about the first yet.
--Bill Seymour
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk