Interpretation of 22.2.6.2.2.2

Benjamin Kosnik bkoz@redhat.com
Mon Feb 18 11:35:00 GMT 2002


> I think the latter behaviour is dictated by an interpretation of 22.2.6.2.2.2
> which considers the 'space' and 'none' fields in the same way, filled with the
> fill char for internal formatting (if len < width, of course), not relevant
> otherwise.

What about 

22.2.6.3 - Template class moneypunct [lib.locale.moneypunct]

1 In the field member of a pattern object, each value symbol, sign, value,
and either space or none appears exactly once. The value none, if present,
is not first; the value space, if present, is neither first nor last. 

2 Where none or space appears, white space is permitted in the format,
except where none appears at the end, in which case no white space is
permitted. The value space indicates that at least one space is required
at that position. 

> In the current libstdc++-v3, on the other hand, locale_facets.tcc, lines
> 1226-1234:
> 
>   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.
>     if (__testipad)
>       __res += string_type(__width - __len, __fill);
>     else
>       __res += __ctype.widen(' ');
>     break;
> 
> Intuitively, it seems to me weird that the standard dictates a 'plain' space in
> one case (internal formatting and len < width) and 'fill-type' spaces otherwise.

Perhaps this should be __fill instead of ' ', uniformly. I believe you 
are correct about this due to 22.2.6.2.2.

I think that, to be standards conformant, space is required. 

-benjamin



More information about the Libstdc++ mailing list