Path: ...!news.mixmin.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: Thu, 23 May 2024 13:11:16 +0100
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <v2nbp4$1o9h6$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me> <87msoh5uh6.fsf@nosuchdomain.example.com>
 <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 May 2024 14:11:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4c7e13270542ea0df2be284fdd57d31b";
	logging-data="1844774"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Ot8Aopz0o1TA2qREtd4hI"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hwmTcOSTFXRKNQfotntpR/41tvM=
Content-Language: en-GB
In-Reply-To: <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
Bytes: 3859

On 23/05/2024 02:21, Thiago Adams wrote:
> Em 5/22/2024 7:53 PM, Keith Thompson escreveu:

>> But const doesn't mean constant.  It means read-only.
>> `const int r = rand();` is perfectly valid.
>>
>> I dislike the C++ hack of making N a constant expression given
>> `const int N = 42;`; constexpr made that unnecessary.  C23 makes the
>> same (IMHO) mistake.
>>
>> If I had a time machine, I'd spell "const" as "readonly" and make
>> "const" mean what "constexpr" now means (evaluated at compile time).
>>
>> [...]
> 
> Everything is a mess: const in C++, the differences from const in C, 
> etc. constexpr in C23 just makes the mess bigger.
> 
> auto is a mess as well not well specified for pointer. not sure if we 
> had this topic here, but auto * p in C is not specified.
> 
> I would remove from C23
> - nullptr
> -auto
> -constexpr
> -embed
> 
> I like the idea of embed but there is no implementation in production so 
> this is crazy!

'embed' was discussed a few months ago. I disagreed with the poor way it 
was to be implemented: 'embed' notionally generates a list of 
comma-separated numbers as tokens, where you have to take care of any 
trailing zero yourself if needed. It would also be hopelessly 
inefficient if actually implemented like that.

I compared it to the scheme in my own language, which could import text 
files, but binary ones didn't really work.

Since then embedding has been considerably improved, so that it works 
like this:

   []char str = sinclude("hello.c")
   []byte data = binclude("hello.exe")

The file-embedding is done by sinclude or binclude. The former adds a 
zero terminator to the embedded file data (expected to be a text file), 
otherwise they are the same.

binclude can initialise any kind of array, including a 2D array of any 
element type, although the data in the file needs to be suitable.

C23's 'embed' was claimed to be more flexible, as you can have 
consecutive 'embed' directives initialising the same array. I can do the 
same:

   []byte file = binclude("hello.exe") + binclude("/cx/big/sql.exe")

   proc main=
       println file.len
   end

This generates an executable of 1077248 bytes, and displays 1050112 when 
run, the combined size of those two embedded binaries. Compiling this 
took 50ms.

("+" here is a compile-time operator that can concatenate constant 
strings or also binary data like this.)

Basically, you are right that the ad hoc features of C23 are messy.

I suspect that ones like 'embed' have been derived from C++ which always 
likes to make things too wide-ranging and much harder to use and 
implement than necessary.