GCC support has been around since gcc 11 apparently. See table at (1). This is available in ubuntu 22.04. The page below also shows support for C26! 1) https://gcc.gnu.org/projects/cxx-status.html#:~:text=C%2B%2B...
The C23 edition of Modern C
221–230 of 360 posts
Re: The C23 edition of Modern C
#222Do they still use 0-terminated strings/char* as the main string type? Is the usage of single linked lists still prevalent as the main container type?
> Do they still use 0-terminated strings/char* as the main string type? Of course, it's still C. > Is the usage of single linked lists still prevalent as the main container type? As far as I can remember, the C standard library has never had any functions that used linked lists. Nor are there any container types, linked lists or otherwise, provided by C. So I'd say this is a question about how people teach and use C,…
Re: The C23 edition of Modern C
#223Earlier quoted context omitted.
I care about performance, when it actually matters to acceptance testing. The less C the merrier. If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.
> If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with. What do you recommend instead?
Re: The C23 edition of Modern C
#224Earlier quoted context omitted.
You can do anything in C that you want to. Of course one can make v-tables and all of that, and even do inheritance. But having the "class" keyword is nice. Having built in support for member functions is nice. Sometimes a person just wants the simplicity of C++ 2003. (In reality I was working on a project where our compiler only supported C++ 2003 and we had a UI library written in C++ 2003 and honestly pure C UI li…
> You can do anything in C that you want to. How about destructors?
Though I've actually seen macro systems that do things akin to destructors, although less automatically.
Re: The C23 edition of Modern C
#225Earlier quoted context omitted.
C99 is still new ! Microsoft tried to kill C by refusing to implement anything that wasn't also in C++. MSVC was 16 years late implementing C99, and implemented only the bare minimum. Their C11 implementation is only 11 years late. I suspect that decades of C being effectively frozen have caused the userbase to self-select to people who like C exactly the way it is (was), and don't mind supporting ancient junk compil…
Most of us liking a good language just did not use MSVC. I do not think many people who appreciate C's simplicity and stability would be happy with C++ / Rust. Zig is beautiful, but still limited in many ways and I would not use it outside of fun projects.
In my experience, Windows devs don't like being told to use a different toolchain. They may have projects tied to Visual Studio, dependencies that are MSVC-only or code written for quirks of MSVC's libc/CRT, or want unique MSVC build features.
I found it hard to convince people that C isn't just C (probably because C89 has been around forever, and many serious projects still target it). I look like an asshole when I demand them to switch to whole another toolchain, instead of me adding a few #ifdefs and macro hacks for some rare nice thing in C.
Honestly, paradoxically it's been easier to tell people to build Rust code instead (it has MSVC-compatible output with almost zero setup needed).
Re: The C23 edition of Modern C
#226Earlier quoted context omitted.
>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. Hindsight is 20/20, remember that. Streams are not that bad of an idea and have been working fine for decades. You haven't named a problem with it other than the fact the operators are used for other stuff in other c…
What they mean is this: struct Foo { int a; float b; std::string c; }; Foo foo; std::cout with no extra code. It's called reflection, where the compiler can generate good-enough code to generate a character-stream serialization of an object without any human intervention.
Re: The C23 edition of Modern C
#227Earlier quoted context omitted.
>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
#228How does "Modern" C compare safety-wise to Rust or Zig?
Re: The C23 edition of Modern C
#229Continuing 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