←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
515 points bwidlar | 1 comments | 15 Oct 24 16:06 UTC | HN request time: 0s | 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(8): >>41850960 #>>41851047 #>>41851166 #>>41851693 #>>41853183 #>>41855660 #>>41857019 #>>41858537 #
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 #
tialaramex ◴[15 Oct 24 19:24 UTC] No.41852165[source]▶
The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators somehow always meant streaming I/O but his evidence is basically the same library feature he's trying to justify. No other language does this, and it's not because they can't it's because it was a bad idea when it was created, it was still a bad idea in 1998, the only difference today is that C++ has a replacement.

The modern fmt-inspired std::print and std::println etc. are much nicer, preserving all the type checking but losing terrible ideas like stored format state, and localisation by default. The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

replies(10): >>41852524 #>>41852543 #>>41853207 #>>41853365 #>>41854242 #>>41854396 #>>41855139 #>>41855859 #>>41858062 #>>41880187 #
dieortin ◴[15 Oct 24 21:14 UTC] No.41853207{3}[source]▶
> The biggest problem is that today C++ doesn't have a way to implement this for your own types easily

I’m not sure about the stdlib version, but with fmtlib you can easily implement formatters for your own types. https://fmt.dev/11.0/api/#formatting-user-defined-types

replies(1): >>41853483 #
1. tialaramex ◴[15 Oct 24 21:50 UTC] No.41853483{4}[source]▶
I think the problem is that your idea of "easy" is "Here's a whole bunch of C++ you could write by hand for each type" while the comparison was very literally #[derive(Debug)]. I wasn't abbreviating or referring to something else, that's literally what Rust programmers type to indicate that their type should have the obvious boilerplate implementation for this feature, in most types you're deriving other traits already, so the extra work is literally typing out the word Debug.