Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

191–200 of 360 posts

Re: The C23 edition of Modern C

#191
post #182
post #95

Earlier quoted context omitted.

> It was on purpose, Microsoft was done with C Indeed, and yet here we are with C23 > The change of heart was the new management, and the whole Microsoft Yeah, agree. To me the turning point was when they created WSL.

Microsoft didn't create C23 and they don't <3 FOSS. They're accepting that they have to deal with FOSS, but installing Windows will still make your Linux system unbootable until you fix it with a rescue disk, among numerous other unfriendly things they do.

I haven't seen Windows fuck up the EFI partition or delete the other entries in a while now. After installing it the machine will usually boot directly into it, but it should be just a toggle in the firmware to switch back to GRUB.

Re: The C23 edition of Modern C

#192

Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all. By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with C…

Skill issue

Re: The C23 edition of Modern C

#193

Earlier quoted context omitted.

> what is wrong with NULL? For starters, you have to #include a header to use it.

Well, I always include stdio.h which includes stddef.h that defines NULL as (void *)0.

In my experience, hardly any source files require studio.h

stddef.h on the other hand is required by most to get size_t

Re: The C23 edition of Modern C

#194

Earlier quoted context omitted.

these features will eventually trickle down into the mainstream, kind of like C11 is doing at the moment also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today

Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.

This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available.

I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20

Re: The C23 edition of Modern C

#195

Earlier quoted context omitted.

these features will eventually trickle down into the mainstream, kind of like C11 is doing at the moment also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today

Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.

most non-embedded and non-legacy codebases could use c23, that's not an insignificant set

Re: The C23 edition of Modern C

#196
post #45
post #2

Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

>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…

Yep; I think of it as "C/C++" and not "C" and/or "C++" i.e. one "multi-paradigm" language with different sets of mix-and-match.

Re: The C23 edition of Modern C

#197

Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all. By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with C…

There are still applications (especially with embedded devices) where you do not dynamically allocate memory or might not even use pointers at all.

Re: The C23 edition of Modern C

#198
post #182

Earlier quoted context omitted.

Microsoft didn't create C23 and they don't <3 FOSS. They're accepting that they have to deal with FOSS, but installing Windows will still make your Linux system unbootable until you fix it with a rescue disk, among numerous other unfriendly things they do.

I haven't seen Windows fuck up the EFI partition or delete the other entries in a while now. After installing it the machine will usually boot directly into it, but it should be just a toggle in the firmware to switch back to GRUB.

That's an improvement! When did they fix that?

Re: The C23 edition of Modern C

#199
post #2

Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

My brief foray into microcontroller land has taught me that C and C++ are very much mixed. It's telling that every compiler toolchain that compiles C++ also compiles C (for some definition of "C"). With compiler flags, GCC extensions, and libraries that are kinda-sorta compatible with both languages, there's no being strict about it. _My_ code might be strict about it, but what about tinyusb? Eventually you'll have t…

> because much (most?) code is not written to a strict C or C++ standard, but is "C/C++" and various extensions.

Absolutely true. I generally insist on folks learning C and C++ interoperability before diving in to all the "Modern C or C++" goodness. It helps them in understanding what actually is going on "under the hood" and makes them a better programmer/debugger.

See also the book Advanced C and C++ Compiling by Milan Stevanovic.

Re: The C23 edition of Modern C

#200
post #29

I was going to ask if there is a good list of C books and then answered my own question. It categorizes _Modern C_ as Intermediate level. https://stackoverflow.com/questions/562303/the-definitive-c-...

Also see Fluent C: Principles, Practices and Patterns by Christopher Preschern.
Post reply on HN