Deutsch   English   Français   Italiano  
<vslehd$28l7$3@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.tomockey.net!news.samoylyk.net!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 3 Apr 2025 09:49:01 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vslehd$28l7$3@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjgjn$1v1n4$1@dont-email.me>
 <vsjk4k$24q5m$1@dont-email.me> <vsjlcp$230a5$1@dont-email.me>
 <vsjmdl$277bk$1@dont-email.me> <VsdHP.1828827$TBhc.1078002@fx16.iad>
 <vskaas$2rit9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 03 Apr 2025 09:49:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d65639e364606db0746acbec737df138";
	logging-data="74407"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+AF3dsb8cu4886lSzJp9k+PrcOx/D4fBM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:KhPdu4uFObptUyYKhbfHaZA5sh0=
In-Reply-To: <vskaas$2rit9$1@dont-email.me>
Content-Language: en-GB
Bytes: 4090

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.