←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
515 points bwidlar | 5 comments | 15 Oct 24 16:06 UTC | HN request time: 0.922s | source
Show context
johnisgood ◴[16 Oct 24 01:56 UTC] No.41854897[source]▶
Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server).

"_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now.

[1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" and "nullptr" just reeks of C++.

That said, Modern C is an incredible book, I have been using it for C99 (which I intend to continue sticking to).

replies(10): >>41854987 #>>41855182 #>>41855214 #>>41855526 #>>41855553 #>>41856362 #>>41857239 #>>41859032 #>>41860073 #>>41935596 #
flohofwoe ◴[16 Oct 24 07:08 UTC] No.41856362[source]▶
auto is mostly useful when tinkering with type-generic macros, but shouldn't be used in regular code (e.g. please no 'almost always auto' madness like it was popular in the C++ world for a little while). Unfortunately there are also slight differences between compilers (IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those differences have been fixed in the meantime).

_BitInt(N) isn't typically used directly but typedef'ed to the width you need, e.g.

    typedef _BitInt(2) u2;
The 'ugly' _B syntax is needed because the combination of underscore followed by a capital letter is reserved in the C standard to avoid collisions with existing code for every little thing added to the language (same reason why it was called _Bool).

AFAIK defer didn't actually make it into C23?

I'm also more on the conservative side when it comes to adding features to the C standard, but IMHO each of the C23 additions makes sense.

replies(2): >>41857227 #>>41857765 #
1. humanrebar ◴[16 Oct 24 09:42 UTC] No.41857227[source]▶
> IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those differences have been fixed in the meantime

Both have compatibly implemented the standard C++ auto. Since 2011 or so.

replies(1): >>41857438 #
2. flohofwoe ◴[16 Oct 24 10:19 UTC] No.41857438[source]▶
Well, not in C :)

Here's an example where Clang and GCC don't agree about the behaviour of auto in C23:

https://www.godbolt.org/z/WchMK18vx

IIRC Clang implements 'C++ semantics' for C23 auto, while GCC doesn't.

Last time I brought that up it turned out that both behaviours are 'standard compliant', because the C23 standard explicitly allows such differing behaviour (it basically standardized the status quo even if different compilers disagreed about auto semantics in C).

PS: at least Clang has a warning now in pedantic mode: https://www.godbolt.org/z/ovj5r4axn

replies(2): >>41859640 #>>41860573 #
3. johnisgood ◴[16 Oct 24 14:44 UTC] No.41859640[source]▶
This difference of implementation in two of the major C compilers leaves a bad taste in my mouth. :/
4. cpeterso ◴[16 Oct 24 15:53 UTC] No.41860573[source]▶
> PS: at least Clang has a warning now in pedantic mode: https://www.godbolt.org/z/ovj5r4axn

Did you mean gcc? Your link shows a gcc error:

  <source>:3:5: error: 'auto' requires a plain identifier, possibly with attributes, as declarator
      3 |     auto* p = &i;
        |     ^~~~
replies(1): >>41860919 #
5. flohofwoe ◴[16 Oct 24 16:19 UTC] No.41860919{3}[source]▶
No, GCC is right to error there, because the code uses a C++-ism (the '*' after 'auto' only makes sense in C++ but not in C).