This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: An even better implementation of 22.2.6.2.2 ??
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 19 Feb 2002 13:24:23 +0000
- Subject: Re: An even better implementation of 22.2.6.2.2 ??
- References: <3C721898.4272F2B@unitus.it>
On Tue, Feb 19, 2002 at 10:19:21AM +0100, Paolo Carlini wrote:
> if I understand well what results from the discussion of yesterday, we
> should not only revert my "fix" for libstdc++/5708, but also
> unconditionally output a "plain" space for the space field (this is
> required by the presence of the space field itself and has nothing to do
> with the filling with the fill char). That is:
>
> case money_base::space:
> // At least one space is required, but if internal
> // formatting is required, an arbitrary number of
> // fill spaces will be necessary.
> __res += __ctype.widen(' ');
> if (__testipad)
> __res += string_type(__width - __len - 1, __fill);
> break;
More or less. (I hate calling widen over and over again, and doing
all kinds of memory allocations during I/O, but that's a whole 'nother
issue.) We need to think about whether the fill characters go before
or after the space, because the standard is entirely unclear on the
point. Generally, they probably shouldn't go between the space and
the currency symbol, because the space is there to separate the
currency symbol from other stuff. Thus,
1000****** DMK
ITL ******1000
This is purely a QOI matter, but once we choose we're probably
stuck with it.
Nathan Myers
ncm at cantrip dot org