Philip Guenther wrote:
>
> On Jun 27, 12:38 pm, Yakov Galka <ybungalob...@gmail.com> wrote:
> ...
>>
>> Maybe it's a silly idea, but we can use whitespace as a separator. It
>> even looks better than _ or '.
>>
>> Is there a place in C++ grammar where "pp-number pp-number" or "pp-
>> number identifier" are legal sequences when converted to tokens at
>> translation phase 7? AFAIK no. If so, we can concatenate these tokens
>> at translation phase 6, just as we do it for string literals. For
>> example:
>>
>> 3.14 159 265 f == 3.14159265f
>
> All human languages have a level of redundancy.  Tenses must match;
> declensions must match; the 'person' of a verb (probably the wrong
> term) must match that of the subject used.
>
> Right now, if you make the typo of leaving out an operator between
> numbers (perhaps as part of a macro expansion) you get a syntax
> error.  This would eliminate that.

Stepping outside the 7-bit ASCII set, the non-breaking space character
could be used to separate digits in numbers, with less risk of hiding
such typos.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
     .      @       .


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sun, 07 Aug 2011 13:07:44 -0600, Niklas Holsti wrote:

>  Philip Guenther wrote:
>>
>>  On Jun 27, 12:38 pm, Yakov Galka<ybungalob...@gmail.com>  wrote: ...
>>>
>>>  Maybe it's a silly idea, but we can use whitespace as a separator. It
>>>  even looks better than _ or '.
>>>
>>>  Is there a place in C++ grammar where "pp-number pp-number" or "pp-
>>>  number identifier" are legal sequences when converted to tokens at
>>>  translation phase 7? AFAIK no. If so, we can concatenate these tokens
>>>  at translation phase 6, just as we do it for string literals. For
>>>  example:
>>>
>>>  3.14 159 265 f == 3.14159265f
>>
>>  All human languages have a level of redundancy.  Tenses must match;
>>  declensions must match; the 'person' of a verb (probably the wrong
>>  term) must match that of the subject used.
>>
>>  Right now, if you make the typo of leaving out an operator between
>>  numbers (perhaps as part of a macro expansion) you get a syntax error.
>>  This would eliminate that.
>
>  Stepping outside the 7-bit ASCII set, the non-breaking space character
>  could be used to separate digits in numbers, with less risk of hiding
>  such typos.

In Unicode the use of the thin space U+2009 is recommended.  This space
is thinner that the normal space.  It's what a typographer would want to
use.

Flo.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 10, 1:50 pm, Florian Kutscherauer<florian.kutschera...@gmx.at>
wrote:
> On Sun, 07 Aug 2011 13:07:44 -0600, Niklas Holsti wrote:
> >  Philip Guenther wrote:
>
> >>  On Jun 27, 12:38 pm, Yakov Galka<ybungalob...@gmail.com>  wrote: ...
>
> >>>  Maybe it's a silly idea, but we can use whitespace as a separator. It
> >>>  even looks better than _ or '.
>
> >>>  Is there a place in C++ grammar where "pp-number pp-number" or "pp-
> >>>  number identifier" are legal sequences when converted to tokens at
> >>>  translation phase 7? AFAIK no. If so, we can concatenate these tokens
> >>>  at translation phase 6, just as we do it for string literals. For
> >>>  example:
>
> >>>  3.14 159 265 f == 3.14159265f
>
> >>  All human languages have a level of redundancy.  Tenses must match;
> >>  declensions must match; the 'person' of a verb (probably the wrong
> >>  term) must match that of the subject used.
>
> >>  Right now, if you make the typo of leaving out an operator between
> >>  numbers (perhaps as part of a macro expansion) you get a syntax error.
> >>  This would eliminate that.
>
> >  Stepping outside the 7-bit ASCII set, the non-breaking space character
> >  could be used to separate digits in numbers, with less risk of hiding
> >  such typos.
>
> In Unicode the use of the thin space U+2009 is recommended.  This space
> is thinner that the normal space.  It's what a typographer would want to
> use.
>
> Flo.
>
I like short spaces aesthetically.
I'm not sure the committee would want to step outside of ascii.  Who
knows, there's always a first time.

As an alternative I was thinking the backtick - ` - ascii 0x27.  It
doesn't have any current use in C++ that I know of so it could be
easily introduced.
The results aren't too bad either:

unsigned long long k = 0xface`beef`dead`babe;

float pi = 3.131`592`654;

It looks sort of like a top line comma :)

Ed


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 11, 5:19 pm, Ed Smith-Rowland<3dw...@verizon.net>  wrote:
>  On Aug 10, 1:50 pm, Florian Kutscherauer<florian.kutschera...@gmx.at>
>  wrote:
>
>
>
>
>
>
>
>  >  On Sun, 07 Aug 2011 13:07:44 -0600, Niklas Holsti wrote:
>  >  >    Philip Guenther wrote:
>
>  >  >>    On Jun 27, 12:38 pm, Yakov Galka<ybungalob...@gmail.com>    wrote: ...
>
>  >  >>>    Maybe it's a silly idea, but we can use whitespace as a separator. It
>  >  >>>    even looks better than _ or '.
>
>  >  >>>    Is there a place in C++ grammar where "pp-number pp-number" or "pp-
>  >  >>>    number identifier" are legal sequences when converted to tokens at
>  >  >>>    translation phase 7? AFAIK no. If so, we can concatenate these tokens
>  >  >>>    at translation phase 6, just as we do it for string literals. For
>  >  >>>    example:
>
>  >  >>>    3.14 159 265 f == 3.14159265f
>
>  >  >>    All human languages have a level of redundancy.  Tenses must match;
>  >  >>    declensions must match; the 'person' of a verb (probably the wrong
>  >  >>    term) must match that of the subject used.
>
>  >  >>    Right now, if you make the typo of leaving out an operator between
>  >  >>    numbers (perhaps as part of a macro expansion) you get a syntax error.
>  >  >>    This would eliminate that.
>
>  >  >    Stepping outside the 7-bit ASCII set, the non-breaking space character
>  >  >    could be used to separate digits in numbers, with less risk of hiding
>  >  >    such typos.
>
>  >  In Unicode the use of the thin space U+2009 is recommended.  This space
>  >  is thinner that the normal space.  It's what a typographer would want to
>  >  use.
>
>  >  Flo.
>
>  I like short spaces aesthetically.

Me too:

0x   face   beef   dead   babe
3.141   592   654   f

>  As an alternative I was thinking the backtick - ` - ascii 0x27.  It
>  doesn't have any current use in C++ that I know of so it could be
>  easily introduced.
>  The results aren't too bad either:

It's not a part of basic source character set. Fortunately EBCDIC has
it.

>  unsigned long long k = 0xface`beef`dead`babe;
>
>  float pi = 3.131`592`654;
>
>  It looks sort of like a top line comma :)

It looks like geographical coordinates to me. Still better than _ or
'.

Yet another, possibility is to use ##:

3.141 ## 592 ## 654 ## f

Doesn't improve readability though, so I don't support it.

-- Yakov Galka


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Le 11/08/2011 16:19, Ed Smith-Rowland a    crit :
>
> On Aug 10, 1:50 pm, Florian Kutscherauer<florian.kutschera...@gmx.at>
> wrote:
>>
>> On Sun, 07 Aug 2011 13:07:44 -0600, Niklas Holsti wrote:

[...]
>>>
>>>  Stepping outside the 7-bit ASCII set, the non-breaking space character
>>>  could be used to separate digits in numbers, with less risk of hiding
>>>  such typos.
>>
>> In Unicode the use of the thin space U+2009 is recommended.  This space
>> is thinner that the normal space.  It's what a typographer would want to
>> use.
>>
>> Flo.
>>
> I like short spaces aesthetically.
> I'm not sure the committee would want to step outside of ascii.  Who
> knows, there's always a first time.

However, using a fixed width font-face (with notepad, e.g.), how would you
show the difference between spaces and short spaces ? And how would you type
this short space with the keyboard ?

> As an alternative I was thinking the backtick - ` - ascii 0x27.  It
> doesn't have any current use in C++ that I know of so it could be
> easily introduced.
> The results aren't too bad either:
>
> unsigned long long k = 0xface`beef`dead`babe;
>
> float pi = 3.131`592`654;
>
> It looks sort of like a top line comma :)
>
> Ed

However, I do like this idea. :)

Leo


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 15.08.2011 15:46, Yakov Galka wrote:
>
> On Aug 11, 5:19 pm, Ed Smith-Rowland<3dw...@verizon.net>   wrote:
>>
>>  As an alternative I was thinking the backtick - ` - ascii 0x27.  It
>>  doesn't have any current use in C++ that I know of so it could be
>>  easily introduced.
>>  The results aren't too bad either:

+1 for backtick from me :-)

>
> It's not a part of basic source character set. Fortunately EBCDIC has
> it.
>

Well, it's a "basic ascii" character, so it should be kind of trivial
to add it to the source character set.

Oh, and note that the backtick is ASCII 0x60
(http://en.wikipedia.org/wiki/Grave_accent#Technical_notes)
(http://www.fileformat.info/info/unicode/char/60/index.htm).

br,
Martin


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 16, 11:29 pm, "Martin B." <0xCDCDC...@gmx.at> wrote:
> On 15.08.2011 15:46, Yakov Galka wrote:
>
>
>
> > On Aug 11, 5:19 pm, Ed Smith-Rowland<3dw...@verizon.net>   wrote:
>
> >>  As an alternative I was thinking the backtick - ` - ascii 0x27.  It
> >>  doesn't have any current use in C++ that I know of so it could be
> >>  easily introduced.
> >>  The results aren't too bad either:
>
> +1 for backtick from me :-)
>
>
>
> > It's not a part of basic source character set. Fortunately EBCDIC has
> > it.
>
> Well, it's a "basic ascii" character, so it should be kind of trivial
> to add it to the source character set.
>
> Oh, and note that the backtick is ASCII 0x60
> (http://en.wikipedia.org/wiki/Grave_accent#Technical_notes)
> (http://www.fileformat.info/info/unicode/char/60/index.htm).
>
> br,
> Martin
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try posting with your ]
> [ newsreader.  If that fails, use mailto:std-cpp-sub...@vandevoorde.com ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

You're right, 0x60 it is.  My examples were correct at least.

Not to shoot down my own idea but in the interest of airing out all
possibilities someone (including the committee) could set aside user-
defined literal operators.
So, say,
long double pi = "3.14159 26535 89793 23846 26433 83279 50288 41971
69399 37510 58209 74944 59230 78164 06286 20899"L;
unsigned long long = "0x babe 1234 dead 8764 fa45 "ULL;

The code for the literal operator could just skip anything that wasn't
an expected digit.  You could put *anything* as a separator almost.

You could even use expanded character sets:
long double u16pi = u"3.14159 26535 89793 23846 26433 83279 50288
41971 69399 37510 58209 74944 59230 78164 06286 20899"L;
where you would have access to narrow spaces if you wanted.

Ed


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello Everyone,
As 64bit word processors become more and more widespread, some of
which also see embedded applications (such as the NetLogic XLP800-
family of system processors) the current syntax in C and C++ for
hexadecimal numbers notation (and thus their notation of encoding
addresses), a long string of hexadecimal digits with the 0x prefix,
become IMHO too long making it hard to interpret and grasp quickly.
Is there a proposal to `enhance' this notation in the next C/C++
standard to make hexadecimal numbers easier to type and understand?
C/C++ can adopt the notation that technical hardware manuals are using
for a long time of using the `_' character to separate between 4 or 8
nibbles (4bit) sequences of digits (e.g. instead of reading
0xFFFF58AE3BBE33AC I think it will be much easier to read
0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
What do you think? Anyone?
Yaniv


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Yaniv Abraham<yaniv1abraham@gmail.com>  writes:
>  C/C++ can adopt the notation that technical hardware manuals are using
>  for a long time of using the `_' character to separate between 4 or 8
>  nibbles (4bit) sequences of digits (e.g. instead of reading
>  0xFFFF58AE3BBE33AC I think it will be much easier to read
>  0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).

I think it would be a very nice feature (no idea if it causes any
conflicts tho).

BTW, it would be useful for _all_ bases, not just hex...

-miles

--
`Life is a boundless sea of bitterness'


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 16, 2:07 pm, Yaniv Abraham<yaniv1abra...@gmail.com>  wrote:
>  Hello Everyone,
>  As 64bit word processors become more and more widespread, some of
>  which also see embedded applications (such as the NetLogic XLP800-
>  family of system processors) the current syntax in C and C++ for
>  hexadecimal numbers notation (and thus their notation of encoding
>  addresses), a long string of hexadecimal digits with the 0x prefix,
>  become IMHO too long making it hard to interpret and grasp quickly.
>  Is there a proposal to `enhance' this notation in the next C/C++
>  standard to make hexadecimal numbers easier to type and understand?
>  C/C++ can adopt the notation that technical hardware manuals are using
>  for a long time of using the `_' character to separate between 4 or 8
>  nibbles (4bit) sequences of digits (e.g. instead of reading
>  0xFFFF58AE3BBE33AC I think it will be much easier to read
>  0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
>  What do you think? Anyone?
>  Yaniv
>
>  --
>  [ comp.std.c++ is moderated.  To submit articles, try posting with your ]
>  [ newsreader.  If that fails, use mailto:std-cpp-sub...@vandevoorde.com ]
>  [              --- Please see the FAQ before posting. ---               ]
>  [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

This idea was floated as an idea for C++0x as a separator that would
be useful for decimal numbers too (I can't find where that proposal is
anymore).
I strongly support this idea personally.

I assume you mean encoding of literals in source code.  Input/Output
can be handled by locales as in http://stackoverflow.com/questions/4163243/thousand-separator-in-c
or


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 6/16/2011 2:07 PM, Yaniv Abraham wrote:
>  As 64bit word processors become more and more widespread, some of
>  which also see embedded applications (such as the NetLogic XLP800-
>  family of system processors) the current syntax in C and C++ for
>  hexadecimal numbers notation (and thus their notation of encoding
>  addresses), a long string of hexadecimal digits with the 0x prefix,
>  become IMHO too long making it hard to interpret and grasp quickly.
>  Is there a proposal to `enhance' this notation in the next C/C++
>  standard to make hexadecimal numbers easier to type and understand?
>  C/C++ can adopt the notation that technical hardware manuals are using
>  for a long time of using the `_' character to separate between 4 or 8
>  nibbles (4bit) sequences of digits (e.g. instead of reading
>  0xFFFF58AE3BBE33AC I think it will be much easier to read
>  0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
>  What do you think? Anyone?

My personal opinion is that the underscore in a numerical literal, as a
symbol that gets simply skipped for the purposes of token parsing (or
what's the right term?), is long overdue in the C++ syntax.  I would
even advocate its use in floating point literals (e.g. for Pi I could
write 3.1415_92653_58979_32384_62643_38327_95 - easy to see there are 32
digits here).

I am relatively certain it's not too difficult to implement, but I've
never attempted to write a grammar rule, so while those get my vote, I
won't argue if an expert says that it's hard to cleanly specify.

V
--
I do not respond to top-posted replies, please don't ask


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Thu, 2011-06-16 at 12:07 -0600, Yaniv Abraham wrote:
> Hello Everyone,
> As 64bit word processors become more and more widespread, some of
> which also see embedded applications (such as the NetLogic XLP800-
> family of system processors) the current syntax in C and C++ for
> hexadecimal numbers notation (and thus their notation of encoding
> addresses), a long string of hexadecimal digits with the 0x prefix,
> become IMHO too long making it hard to interpret and grasp quickly.
> Is there a proposal to `enhance' this notation in the next C/C++
> standard to make hexadecimal numbers easier to type and understand?
> C/C++ can adopt the notation that technical hardware manuals are using
> for a long time of using the `_' character to separate between 4 or 8
> nibbles (4bit) sequences of digits (e.g. instead of reading
> 0xFFFF58AE3BBE33AC I think it will be much easier to read
> 0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
> What do you think? Anyone?

I think you are to late.
This would clash with user-defined literals, wouldn't it?

int operator "" _1234 (int n) { return 17; }

0x12cd_1234;

/MF



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Magnus Fromreide <cscpp@magfr.users.lysator.liu.se> writes:
>> 0xFFFF58AE3BBE33AC I think it will be much easier to read
>> 0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
>
> I think you are to late.
> This would clash with user-defined literals, wouldn't it?
>
> int operator "" _1234 (int n) { return 17; }
>
> 0x12cd_1234;

Hmm, how about using apostrophe ('):

0x12cd'1234

1'234'567

Maybe a little bit less pretty than _, but still pretty good I think...

-miles

--
Yo mama's so fat when she gets on an elevator it HAS to go down.


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 24, 2:32 am, Magnus Fromreide
<cs...@magfr.users.lysator.liu.se> wrote:
> On Thu, 2011-06-16 at 12:07 -0600, Yaniv Abraham wrote:
> > Hello Everyone,
> > As 64bit word processors become more and more widespread, some of
> > which also see embedded applications (such as the NetLogic XLP800-
> > family of system processors) the current syntax in C and C++ for
> > hexadecimal numbers notation (and thus their notation of encoding
> > addresses), a long string of hexadecimal digits with the 0x prefix,
> > become IMHO too long making it hard to interpret and grasp quickly.
> > Is there a proposal to `enhance' this notation in the next C/C++
> > standard to make hexadecimal numbers easier to type and understand?
> > C/C++ can adopt the notation that technical hardware manuals are using
> > for a long time of using the `_' character to separate between 4 or 8
> > nibbles (4bit) sequences of digits (e.g. instead of reading
> > 0xFFFF58AE3BBE33AC I think it will be much easier to read
> > 0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
> > What do you think? Anyone?
>
> I think you are to late.
> This would clash with user-defined literals, wouldn't it?
>
> int operator "" _1234 (int n) { return 17; }
>
> 0x12cd_1234;
>

I'd reserve literals beginning with _ for system defined use (in much
the same way that it's considered bad style to have anything with a
name beginning with _, although the standard only refers to _ followed
by upper case letter).

Especially as a readable numeric separator is far more useful than a
user defined literal (I've frequently missed the former, only rarely
the latter).


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Victor Bazarov wrote:
>
> On 6/16/2011 2:07 PM, Yaniv Abraham wrote:
>>
>>  As 64bit word processors become more and more widespread, some of
>>  which also see embedded applications (such as the NetLogic XLP800-
>>  family of system processors) the current syntax in C and C++ for
>>  hexadecimal numbers notation (and thus their notation of encoding
>>  addresses), a long string of hexadecimal digits with the 0x prefix,
>>  become IMHO too long making it hard to interpret and grasp quickly.
>>  Is there a proposal to `enhance' this notation in the next C/C++
>>  standard to make hexadecimal numbers easier to type and understand?
>>  C/C++ can adopt the notation that technical hardware manuals are using
>>  for a long time of using the `_' character to separate between 4 or 8
>>  nibbles (4bit) sequences of digits (e.g. instead of reading
>>  0xFFFF58AE3BBE33AC I think it will be much easier to read
>>  0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
>>  What do you think? Anyone?
>
> My personal opinion is that the underscore in a numerical literal, as a
> symbol that gets simply skipped for the purposes of token parsing (or
> what's the right term?), is long overdue in the C++ syntax.  I would
> even advocate its use in floating point literals (e.g. for Pi I could
> write 3.1415_92653_58979_32384_62643_38327_95 - easy to see there are 32
> digits here).

Good idea. For an example of a language where it is already
implemented see Ada, where you can put underscores between literal
digits (in any base, and for integer literals or floating literals)
but not as the first or last character of the literal. Underscores are
very useful for making long literals readable.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
     .      @       .


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

ThosRTanner <ttanner2@bloomberg.net> writes:
>> This would clash with user-defined literals, wouldn't it?
>>
>> int operator "" _1234 (int n) { return 17; }
>>
>> 0x12cd_1234;
>
> I'd reserve literals beginning with _ for system defined use (in much
> the same way that it's considered bad style to have anything with a
> name beginning with _, although the standard only refers to _ followed
> by upper case letter).

I disagree.

Literals starting with "_" should be available for users, as they are
much more readable, and feel more natural for longer names (more than
one or two characters).  That's the reason, presumably, that many
examples one sees of user-defined literals have names starting with
"_"....

It's a separate namespace, so there's no conflict with traditional
identifiers (and "bad style" is irrelevant).

-Miles

--
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 25, 11:06 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:
> Victor Bazarov wrote:
>
> > On 6/16/2011 2:07 PM, Yaniv Abraham wrote:
>
> >>  As 64bit word processors become more and more widespread, some of
> >>  which also see embedded applications (such as the NetLogic XLP800-
> >>  family of system processors) the current syntax in C and C++ for
> >>  hexadecimal numbers notation (and thus their notation of encoding
> >>  addresses), a long string of hexadecimal digits with the 0x prefix,
> >>  become IMHO too long making it hard to interpret and grasp quickly.
> >>  Is there a proposal to `enhance' this notation in the next C/C++
> >>  standard to make hexadecimal numbers easier to type and understand?
> >>  C/C++ can adopt the notation that technical hardware manuals are using
> >>  for a long time of using the `_' character to separate between 4 or 8
> >>  nibbles (4bit) sequences of digits (e.g. instead of reading
> >>  0xFFFF58AE3BBE33AC I think it will be much easier to read
> >>  0xFFFF58AE_3BBE33AC or even 0xFFFF_58AE_3BBE_33AC).
> >>  What do you think? Anyone?
>
> > My personal opinion is that the underscore in a numerical literal, as a
> > symbol that gets simply skipped for the purposes of token parsing (or
> > what's the right term?), is long overdue in the C++ syntax.  I would
> > even advocate its use in floating point literals (e.g. for Pi I could
> > write 3.1415_92653_58979_32384_62643_38327_95 - easy to see there are 32
> > digits here).
>
> Good idea. For an example of a language where it is already
> implemented see Ada, where you can put underscores between literal
> digits (in any base, and for integer literals or floating literals)
> but not as the first or last character of the literal. Underscores are
> very useful for making long literals readable.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>      .      @       .
>

(reposting since it looks like it didn't work yesterday)

Maybe it's a silly idea, but we can use whitespace as a separator. It
even looks better than _ or '.

Is there a place in C++ grammar where "pp-number pp-number" or "pp-
number identifier" are legal sequences when converted to tokens at
translation phase 7? AFAIK no. If so, we can concatenate these tokens
at translation phase 6, just as we do it for string literals. For
example:

3.14 159 265 f == 3.14159265f
271 828 183 == 271828183
0x 1234 abcd LL == 0x1234abcdLL

--
Yakov Galka


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 27, 12:38 pm, Yakov Galka <ybungalob...@gmail.com> wrote:
...
> Maybe it's a silly idea, but we can use whitespace as a separator. It
> even looks better than _ or '.
>
> Is there a place in C++ grammar where "pp-number pp-number" or "pp-
> number identifier" are legal sequences when converted to tokens at
> translation phase 7? AFAIK no. If so, we can concatenate these tokens
> at translation phase 6, just as we do it for string literals. For
> example:
>
> 3.14 159 265 f == 3.14159265f

All human languages have a level of redundancy.  Tenses must match;
declensions must match; the 'person' of a verb (probably the wrong
term) must match that of the subject used.

Right now, if you make the typo of leaving out an operator between
numbers (perhaps as part of a macro expansion) you get a syntax
error.  This would eliminate that.

Yes, it's unambiguous to make whitespace ignored inside a scalar**.
Does the readability of permitting whitespace balance losing the error
checking rejecting whitespace?

While I've never _used_ perl's syntax of permitting underbars inside
numbers, neither have a I been bitten by it.  I *have* been bitten by
other quirks of perl's syntax that make typos into valid expressions.


Philip Guenther

** though not so in perl, for example: 'x' is an operator, so 0x10 !=
0 x 10


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]