Bill Seymour <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > Those look fine to me.
> > I'll also take the suggestion to put frac_digits() in the public > interface and "fraction digits" in the text of the documentation. > fine > > Daryle Walker and Ilya Buchkin are raising some important issues > that probably go away if the scale is part of the type. I'm not sure how to decide if making the scale part of the type is a good idea. Do users really want that? Suppose we apply the LSP (*1) to decimals of different scales, that is, we subsitute a decimal of one scale with a decimal of a different scale, how much does the change affect the program behaviour? If the answer is "not much", it would indicate that type equivalence between decimals of different scales is important, thus making the scale part of the type will be more of a burden than a gain. OTOH, if it is important not to mix/substitue decimals of different scales without explicit intervention, then the scale should be part of the type. If the motivation is _only_ to allow for more efficient algorithms and more compact representations, then I don't think coupling the scale with the type is the right choice. (*1) Liskov Substitution Principle http://www.objectmentor.com/resources/articles/lsp.pdf > > 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(); Good. > 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() > Hmmmm. Why not: significand() (or mantisa()), and one()? Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
