←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
397 points bwidlar | 3 comments | 15 Oct 24 16:06 UTC | HN request time: 0.001s | source
Show context
belter ◴[15 Oct 24 17:30 UTC] No.41850897[source]▶
Important reminder just in the Preface :-)

Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

replies(6): >>41850960 #>>41851047 #>>41851166 #>>41851693 #>>41853183 #>>41855660 #
jasode ◴[15 Oct 24 18:38 UTC] No.41851693[source]▶
>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

Where "mixing C/C++" is helpful:

- I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged.

- For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf in C++ instead of newer C++ cout.

Where the "C is a totally different language from C++" perspective is helpful:

- knowing that compilers can compile code in "C" or "C++" mode which has ramifications for name mangling which leads to "LINK unresolved symbol" errors.

- knowing that C99 C23 has many exceptions to "C++ is a superset of C" : https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B...

replies(4): >>41851853 #>>41852165 #>>41852449 #>>41856015 #
accelbred ◴[15 Oct 24 18:52 UTC] No.41851853[source]▶
C++ can seamlessly include C89 headers.

The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++.

Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

replies(3): >>41851979 #>>41852136 #>>41852251 #
1. Conscat ◴[15 Oct 24 19:21 UTC] No.41852136{3}[source]▶
Clang supports C11 - 23 in C++, as well as some future C features like fixed-point integers. The main pain points with Clang are just the fundamental differences like void* and char, which don't typically matter much at an interoperability layer.
replies(1): >>41856217 #
2. flohofwoe ◴[16 Oct 24 06:40 UTC] No.41856217[source]▶
There's a lot of subtle differences between 'proper' C and the C subset of C++, since C++ uses C++ semantics everywhere, even for its C subset.

Many C++ coders are oblivious to those differences (myself included before I switched from 'mainly C++' to 'mainly C') because they think that the C subset of C++ is compatible with 'proper' C, but any C code that compiles both in a C++ and C compiler is actually also a (heavily outdated) subset of the C language (so for a C coder it takes extra effort to write C++ compatible C code, and it's not great because it's a throwback to the mid-90s, C++ compatible C is potentially less safe and harder to maintain).

For instance in C++ it's illegal to take the address of an 'adhoc-constructed' function argument, like:

    sum(&(bla_t){ .a = 1, .b = 2, .c = 3, .d = 4 });
(godbolt: https://www.godbolt.org/z/r7r5rPc6K)

Interestingly, Objective-C leaves its C subset alone, so it is always automatically compatible with the latest C features without requiring a new 'ObjC standard'.

replies(1): >>41856478 #
3. pjmlp ◴[16 Oct 24 07:26 UTC] No.41856478[source]▶
Because Objective-C initial proposal is that everything that isn't touched by Smalltalk like code, clearly in brackets or @annotarions, is plain C.

The pre-processor original compiler, before the GCC fork, would leave everything else alone, blindly copying into the generated C file.