←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
515 points bwidlar | 1 comments | | HN request time: 0.296s | source
Show context
belter ◴[] 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 ◴[] 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 ◴[] 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 #
chipdart ◴[] No.41858062[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.

I think this is a very lazy and somewhat conspiratorial take.

C++'s IO stream library, along with C++'s adoption of std::string, is a response to and improvement over C's standard library support for IO. That alone makes it an invaluable improvement. It's easy and very lazy to look back 30 years ago and badmouth things done back then.

It's also easy to complain about no one proposing changes when literally anyone, including you, can propose changes. The only need to do the legwork and put their money where their mouth is. The funny part is that we see frameworks putting together their own IO infrastructure and it ends up being not good, such as Qt's take on IO.

But talk is cheap and badmouthing doesn't require a pull request.

replies(1): >>41880241 #
1. int_19h ◴[] No.41880241[source]
The problem is precisely that C++ iostream library was, in practice, not an improvement on C stdio in many ways. Some of us were actually there 30 years ago, and even right after C++98 was standardized, it was pretty common for (then-)modern C++ projects to adopt all of stdlib except for iostreams (and locales/facets, another horrible wart).