This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] 27_io/ios_manip_basefield.cc
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 26 Feb 2002 12:09:44 -0800 (PST)
- Subject: Re: [RFC] 27_io/ios_manip_basefield.cc
> The LWG has tentatively declared the ambiguity "not a defect". For the
> case of hex numbers, the first exposition above is unambiguously correct.
Really? I agree it looks prettier, but I think the standard is very
ambiguous on this issue. Am I missing some discussion? I only see
Howard's initial post.
The wording in question is:
22.2.2.2.2 - num_put virtual functions
16- For integral types, punct.thousands_sep() characters are inserted into
the sequence as determined by the value returned by punct.do_grouping()
using the method described in lib.facet.numpunct.virtuals
It sounds like "the sequence" is defined to be just digits, excluding
showbase info. Is this correct?
> For octal, either of the above should be parsed, and either may be
> produced. I lean toward the first, for consistency with the hex case,
> but whichever is simpler to code is fine.
I agree, consistency would be fantastic for output.
> Of course. Which is more readable:
>
> a34682983792cd3e
> a346 8298 3792 cd3e
Ok, this makes sense, thanks for the example.
Paolo, can you post your patch for this? It sounds like you've already
finished implementing the correct approach.
-benjamin