Boost logo

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