Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sun, 26 May 2024 02:09:13 +0100
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <v2u23q$33ua5$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me>
 <9be0c55c-38f8-496c-b335-84ad281e1753@gmail.com>
 <v2nc5h$1oban$1@dont-email.me>
 <c5866b5a-0314-4e70-af56-a86b63986b0c@gmail.com>
 <v2nfai$1ougd$1@dont-email.me>
 <cf267279-e9cf-415f-898c-f5830a997529@gmail.com>
 <87ed9s42sb.fsf@nosuchdomain.example.com>
 <f5774ff3-d2b0-4787-b16c-3b193dc418ef@gmail.com>
 <87bk4v2du1.fsf@nosuchdomain.example.com>
 <ec20f752-6132-40f5-a4e8-f884746d2f3a@gmail.com>
 <87v8330xq3.fsf@nosuchdomain.example.com>
 <97c17a49-a940-42ff-83b8-df755fb6e88e@gmail.com>
 <v2sgm6$2rle2$1@dont-email.me>
 <3510a9be-2962-4f8a-a040-62e2716eed92@gmail.com>
 <v2sv8a$2u3d4$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 26 May 2024 03:09:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8e9185d4e0820a2f5b79db78e2103a30";
	logging-data="3275077"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18CJBCNftnZuudy4fIcxoyw"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:vy1DPg7M0tZflj1+kfivqQrTwCY=
In-Reply-To: <v2sv8a$2u3d4$1@dont-email.me>
Content-Language: en-GB
Bytes: 4561

On 25/05/2024 16:14, David Brown wrote:
> On 25/05/2024 13:19, Thiago Adams wrote:

>> The justification for C was VLA. They should consider VLA not VLA if 
>> it has a constant expression. In other words, better break this than 
>> create a mess.
>> #define makes the job of constexpr.
>>
> 
> #define is one way to make named items that can be used in constant 
> expressions, yes.  But if it can be done using #define or constexpr, I 
> think constexpr is the neater choice.  Opinions can vary - that's my 
> opinion.

Before 'constexpr' (and it still is 'before' as implementations are 
rare), there were three disparate ways of emulating named constants in C:

   #define A 100

   enum {B = 200};

   int const C = 300;

None of them fully do the job of the named constant feature I've used in 
my own languages (and which I also briefly had in my C compiler).

With 'constexpr' there are now 4 ways of doing it:

   constexpr int D = 400;

Here are some characteristics of true named constants and how those 
methods fare:

                  #define  enum      const  constexpr

Scope rules      N        Y         Y      Y
No & addr-of     Y        Y         N      N?
Any type         Y?       N         Y      Y   Any int/float
Non-VLA bounds   Y        Y         N      Y?
Switch-case?     Y        Y         N      Y?
Reduce           Y        Y         ?      Y?  2+3 => 5
Can't Mod value  Y        Y         N      N?  By any means
Not Context sens N        Y         Y      Y   Value may vary by context
Single reeval    N        Y         Y      Y   Expr processed once
Lower case OK    N?       Y         Y      Y

Ideally a column would have all Ys. None of these manage that, but 
'enum' comes nearest. However it has a problem: it wasn't designed for 
this task, which is just a useful by-product. So it looks odd.

With const/constexpr, even if the language can't stop attempts to change 
the value, sometimes those attempts are trapped (via read-only mem etc). 
That's not ideal either.

Regarding 'Not context sensitive', consider:

----------------------
#include <stdio.h>

enum {a = 100};

#define M (a+1)

enum {b = M};

int main(void) {
     enum {a=777};

     printf("b = %d\n", b);
     printf("M = %d\n", M);
}
----------------------

The output is 101 and 778. The value of M is 101 when used to define 
`b`, and 778 later on.

'Single reevaluation' refers to the fact that the expansion of a #define 
macro will be repeated at each invocation side, so parsing, evaluation 
and reduction of the expression will be done multiple times. It's just 
inefficient.

It might also vary, not just because of the last point, but because 
there aren't enough parentheses or something so combines differently 
with surrounding context.