Re: [RFC] 27_io/ios_manip_basefield.cc

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Tue, Feb 26, 2002 at 09:39:26AM -0800, Benjamin Kosnik wrote:
> > ... The only tricky point is that we cannot simply change 
> > the condition if (__grouping.size() && __dec) to (__grouping.size())) 
> > since, as is, __add_grouping is not able to deal correctly with numbers 
> > beginning with 0x or 0X or 0 (when showbase is true, I mean). But I can 
> > work out this.
> 
> Great. I'd suggest looking at the message identified earlier, from the 
> library reflector. The grouping status of numbers with 0x, 0X, 0 seems to 
> be unclear. (Ie, it's unknown how to treat them.) There's supposed to be 
> a DR about this too, but it was never written.
> 
> 0x123,456
>       or
> 0x,123,456
> 
> 0123,456
>       or
> 0,123,456

The LWG has tentatively declared the ambiguity "not a defect".  For the
case of hex numbers, the first exposition above is unambiguously 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'm up for the second interpretation, which should be easier to 
> implement and doesn't special case any digits. In general, I think grouping 
> for hex numbers makes little sense.  Can anybody think of a reason to do so?

Of course.  Which is more readable:

  a34682983792cd3e
  a346 8298 3792 cd3e

We group hex numbers (or should!) for the same reasons that we group 
decimal numbers (or should!).  In some ways grouping hex numbers is even
more valuable, because the divisions (may) correspond to word boundaries.

Nathan Myers
ncm at cantrip dot org