Sujet : Re: Hex string literals (was Re: C23 thoughts and opinions)
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 18. Jun 2024, 23:00:13
Autres entêtes
Organisation : None to speak of
Message-ID : <87frt9zzbm.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
David Brown <
david.brown@hesbynett.no> writes:
On 18/06/2024 02:19, Keith Thompson wrote:
[...]
I forgot about digit separators.
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is
borrowed from C++. Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)
>
Commas would be entirely unsuitable here, since half the world uses
decimal commas rather than decimal points. I think underscores are a
nicer choice, used by many languages, but C++ could not use
underscores due to their use in user-defined literals, and C followed
C++.
C already uses '.' as the decimal point, though half the world uses ','.
That's already US-centric. ',' is unusable as a digit separator because
`123,456` already has any of several meanings, depending on the context.
If it weren't for that issue, I think that using ',' as a digit separator
would be no more problematic than using '.' as a decimal point. And C++
and C23 already use the apostrophe as a digit separator, which is likely
to be jarring to anyone outside Switzerland.
In any case, as discussed, I'm not proposing an ignorable digit
separator for hex string literals.
[...]
I don't see the benefit here. This is C - the programmer is expected
to get the type right, and I think it would be rare to get it wrong
(or worse wrong than forgetting "unsigned") in a case like this. So
the extra type checking here has little or no benefit. (In general, I
am a fan of stronger type checking, but it is only important if it
catches real errors.)
>
The end result is completely identical to the user - adding
"hex(true)" makes no difference to the generated code. Thus it is
just an implementation detail which the user should not have to deal
with.
The point isn't to change the generated code. The point is to let
programmers say more directly what they mean: "Treat the contents
of this file as an array of unsigned char", rather than the existing
"Treat the contents of this file as a sequence of comma-separated
integer constant expressions (which, by the way, I'm going to use
in an initializer for an array of unsigned char)".
(I don't think either of us is going to change our minds on the
esthetics. And yes, that sentence isn't entirely grammatically
correct.)
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */