This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Proposal


Zack Weinberg wrote:-

> Let's get back to what you originally proposed.  You want to be able
> to write 1000000 as 1_000_000 for legibility.  This would be easy to
> implement and I agree that it would be an improvement.  What you need
> to do is decide exactly what the extended syntax is supposed to be.
> For instance, are you allowed to write any of the following?
> 
> 	16777216_UL  [1]
> 	16777216U_L  [2]
> 	0._1234      [3]
> 	0x_1234      [4]
> 	12.34_e+56   [5]
> 	12.34e_+56   [6]
> 
> All but the last are legitimate "preprocessing numbers".  I can tell
> you right now that I'll be a lot more receptive to an extension that
> doesn't change the definition of a preprocessing number.

I don't think we want to accept anything that changes the pp-number
definition; I consider it set it stone.

I've labelled your examples above.  [6] is not a pp-number, so I'd
rule it out from the start.

For the rest, I see two reasonable things to say:

1) A pp-number with '_' in it is interpreted as if all '_' were stripped
   out initially.

2) We allow _ only in the integer part of decimals / hex / floats, but
   anywhere and anyhow in those parts.  Not valid in suffixes.  Interpreted
   as if the '_' were stripped out.  This would invalidate [2], [3] and [5].

Anything more complex is probably not worth it.  1) is appealling
merely because it is simple and unambiguous.

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]