Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Wed, 22 May 2024 22:11:44 +0200
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <v2lji1$1bbcp$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 22 May 2024 22:11:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c8dad87a6d02311a34acbc1393ea65af";
	logging-data="1420697"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18GRUhoOwKl8GYrWrWu0ijG9FMhN4/DVsQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rICGsEqFfFfd0WXhSs45RyDKzsM=
Content-Language: en-GB
In-Reply-To: <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
Bytes: 4907

On 22/05/2024 19:42, Thiago Adams wrote:
> On 22/05/2024 13:55, David Brown wrote:
>> In an attempt to bring some topicality to the group, has anyone 
>> started using, or considering, C23 ?  There's quite a lot of change in 
>> it, especially compared to the minor changes in C17.
>>
>> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>
>> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)>
>> <https://en.cppreference.com/w/c/23>
>>
>> I like that it tidies up a lot of old stuff - it is neater to have 
>> things like "bool", "static_assert", etc., as part of the language 
>> rather than needing a half-dozen includes for such basic stuff.
>>
>> I like that it standardises a several useful extensions that have been 
>> in gcc and clang (and possibly other compilers) for many years.
>>
>> I'm not sure it will make a big difference to my own programming - 
>> when I want "typeof" or "chk_add()", I already use them in gcc.  But 
>> for people restricted to standard C, there's more new to enjoy.  And I 
>> prefer to use standard syntax when possible.
>>
>> "constexpr" is something I think I will find helpful, in at least some 
>> circumstances.
> 
> I am waiting MSVC support. There are a lot of simple features MSVC could 
> implement and deliver in small increments. But it is very slow.

MSVC is primarily a C++ compiler - the C support is more of a leftover 
from the previous century, with a few post-C90 features as an 
afterthought.  Surely for C development on Windows, rather than C++, 
you'd look for something better?

> 
> I am would use today if I had.
> 
>   - #warning
>   - [[nodiscard]]
>   - typeof
>   - digit separators
>   - bool true, false
> 

I use these today in C, except the digit separators (I use them in C++). 
  But as I say, it's nice to see them as standard rather than just 
common extensions.

> I am not planning to use:
> 
>   - enum with specific types.

I haven't found a use for these in C++, and I'm not sure I'll need them 
in C either.  I sometimes have ordinary enum types in bitfields for 
specific sizes.

>   - #elifdef

The will slightly neaten some of my pre-processor handling.  My strong 
preference for preprocessor symbols for conditional compilation and the 
like is to have symbols that are always defined, but to different 
values, and use "#if" checks rather than "#ifdef" - when combined with 
gcc warnings, it makes it far easier to catch spelling mistakes, and it 
makes it easy to jump in the code to where the symbol is defined.  But 
#ifdef checks do turn up, and this will give marginally neater code.

>   - nullptr

I am fond of nullptr in C++, and will use it in C.  Like most of the C23 
changes, it's not a big issue - after all, you get a lot of the same 
effect with "#define nullptr (void*)(0)" or similar.  But it means your 
code has a visual distinction between the integer 0 and a null pointer, 
and also lets the compiler or other static checking system check better 
than using NULL would.  (And I don't like NULL - I dislike all-caps 
identifiers in general.)

>   - auto

I use that occasionally in gcc, as __auto_type.  It can be helpful in 
macros.  I might use it more when it is standardised.  (I use auto in 
C++ a bit more often.)

>   - constexpr

I will definitely use that.  Sometimes I want a constant expression for 
things like array sizes or static initialisers, and want to calculate 
it.  constexpr gives you that without having to resort to macros.  (I'd 
perhaps be even happier if I could just use const, as I can in C++.)

> 
> Not sure
>   - empty initializer
> 

I don't see that one being a big hit, at least for me.  But I see little 
benefit in /not/ allowing it in the language, so it seems a sensible 
addition.