Re: "A diagram of C23 basic types"

On 4/3/2025 2:49 AM, David Brown wrote:

On 02/04/2025 23:31, Janis Papanagnou wrote:

On 02.04.2025 18:20, Scott Lurndal wrote:

Muttley@dastardlyhq.com writes:

On Wed, 2 Apr 2025 16:33:46 +0100
bart <bc@freeuk.com> gabbled:

On 02/04/2025 16:12, Muttley@DastardlyHQ.org wrote:

Meh.

>
What's the problem with it? Here, tell me at a glance the magnitude of
this number:
>
     10000000000

>
And how often do you hard code values that large into a program? Almost
never I imagine unless its some hex value to set flags in a word.

>
I can't tell generally; it certainly depends on the application
contexts.
>
And of course for bases lower than 10 the numeric literals grow
in length, so its usefulness is probably most obvious in binary
literals. But why restrict a readability feature to binary only?
>
It's useful and it doesn't hurt (WRT compatibility).
>

>
Every day, several times a day. 16 hex digit constants are very
common in my work.  The digit separator really helps with readability,
although I would have preferred '_' over "'".

>
Obviously a question of opinion depending on where one comes from.
>
I see a couple options for the group separator. Spaces (as used in
Algol 68) are probably most readable, but maybe a no-go in "C".
Locale specific separators (dot and comma vs. comma and dot, in
fractional numbers) and the problem of commas infer own semantics.
The single quote is actually what I found well suited in the past;
it stems (I think) from the convention used in Switzerland. The
underscore you mention didn't occur to me as option, but it's not
bad as well.
>

 Once you have eliminated punctuation that would already have a different meaning in the syntax of the language, you very quickly get down to three choices, AFAICS - underscore, single quote or double quote.  When C++ added digit separators, they had already used underscore for user- defined literals, so that was ruled out.  I don't know if double quotation marks could have been used, or they were ruled out for other reasons, but C++ settled on single quotation marks.  Then C followed suit, because re-inventing an incompatible wheel would have been insane.
 With hindsight, it might have been nicer to use underscore for digit separators and single quote marks for user-defined literals in C++ (in the manner of attributes in Ada), but the fact that underscore is effectively a letter in C and C++ was very relevant for its choice in user-defined literals.
 

Could have made sense to make a distinguishing rule that whether or not _ is understood as a digit or user-defined literal depends on whether the following character is also a valid digit.
So, 0x0000_0000 is a digit separator, because it is followed by a digit.
Can note that, in my case, whether 'z' or 'x' are allowed in a literal depends on both the base (only allowed for now in hex and binary literals, but not octal or decimal) and the suffix (they are only valid if the number token would end with a width-specifying number suffix, *1).
But, one could argue that this does make tokenizing more annoying, as whether to end or continue the token depends on characters following the character in question (so, there is a need to add some complexity to "what if?" it slightly...).
This was in turn because Verilog literal syntax, say, 16'h9zz1, wasn't really a fit for C either...
*1: Say, iNN, uiNN, or uNN, where NN being the number of bits.
   0x12345678i32  //exact-width, 32-bit signed literal.
   0x12345678u32  //exact-width, 32-bit unsigned literal.
...