$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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