Re: C23 thoughts and opinions

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.