Re: C23 thoughts and opinions

On 22/05/2024 22:26, Thiago Adams wrote:

On 22/05/2024 17:11, David Brown wrote:

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>
>

>

  - 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++.)

 I am curious for that. Do you have a sample?
 

If I try to be precise about the terms "constant expression", "integer constant expression", etc., I suspect I will get the details wrong unless I spend a lot of time checking carefully.  So I hope it is good enough for me to be a bit lazy and quote the error messages from gcc (with "-std=c23 -Wpedantic").
With this code, compilation fails "initialiser element is not a constant" for y.
     int x = 100;
     int y = x / 20;
     int zs[y];
With this code, compilation fails because the zs is actually a VLA, and "variably modified 'zs' at file scope" is not allowed.
     const int x = 100;
     const int y = x / 20;
     int zs[y];
This code, however, is fine:
     constexpr int x = 100;
     constexpr int y = x / 20;
     int zs[y];
This also works, even for older standards:
     enum { x = 100 };
     enum { y = x / 20 };
     int zs[y];
But constexpr works for other types, not just "int" which is the type of all enumeration constants.  (And "enum" constants are a somewhat weird way to get this effect - "constexpr" looks neater.)
And in general, I like to be able to say, to the compiler and to people reading the code, "this thing is really fixed and constant, and stop compiling if you think I am wrong" rather than just "I promise I won't change this thing - or if I do, I don't mind the nasal daemons".

 

>
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.

 This is what I use
struct X x = {0};
But I can do a find-replace and change everything to {}
 

You could, but I don't really see the point of such a change.  But in new code it would be fine to write "= {}" rather than "= { 0 }".

When I create samples, I use new feature like nullptr and {}.
The problem I see is to use these features in real code, and create a mess of styles.
 

I think you need significant motivation to justify changing style in existing code, and I don't see anything here that would make me want to change existing C17 code to C23 code.  But when writing new code, I'd use the new features.