> isn’t "C vs C++,"

Perhaps be more careful in trying to make LLM output look like you wrote it yourself. The incongruent punctuation mark types, with curly apostrophes and straight double quotes mixed together in the same text, are a dead giveaway.

You might be interested in the scpptool feature to help convert C code to a subset of C that will also compile as C++ (under clang++ at least) [1]. While many of the necessary modifications are fairly trivial, some of them aren't completely so. For example, C++ does not allow `goto`s that would skip over the declaration/initialization of a variable that would be accessible after the jump. So getting the C code to work as C++ can involve some (automatic) code restructuring.

Another annoying detail is that C++ doesn't seem to like forward references of `enum`s. That is, while

    struct A* a_ptr;

    enum A* a_ptr;

One arguable benefit of keeping your C code compatible with (or at least convertible to) C++, is that you can theoretically use scpptool's auto-translation feature as build step to produce memory-safe executables from C code via transpilation to a memory-safe subset of C++.

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

The "stronger type system" is mostly a myth in my opinion. It was true in the past in pre-prototype C. The void pointer rules are better in C IMHO as they avoid unneeded casts (that then remove more type safety) and FAMs and variably-modified types can express things C++ simply can't do well.

Not sure if you're aware, but defer is proposed for C2Y [1]. It's already available in Clang behind a compiler flag. It is interesting how the languages continue to diverge.

[1] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf

I appreciate that restrict isn't there, because it is yet another UB source, programmer knows not to do errors kind of attitude, and secondly no one seems to care enough to write a language proposal for it.

About half of them read as "I tried to use C++ as a worse C" e.g. using struct initilisation instead of constructors, using malloc instead of new or new[].

My pet peeve with C++ is that the sequence point operator can be overloaded at which point it stops being a sequence point.

> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases.

...I've seen this more often in the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, C++ coders usually have a very outdated view of C.

> I’d also be curious which C constructs people still genuinely miss in modern C++.

Not implementing the full C99 designated init feature set was a huge missed opportunity in C++20. Every single feature of C99 designated init is important and clicks with the other features and the rest of the language, take one or two away and it becomes mostly useless (e.g. the order requirement in C++20 means that designated init is only useful for trvial structs).

It's especially tragic because Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.

> The interesting part to me isn’t "C vs C++," but where the languages diverged philosophically

IMHO this "schism" was completely unnecessary and only happened because of ignorance and hubris by the C++ designers. Objective-C shows that C can be extended with radical new features but without messing up the "C side" (e.g. ObjC features don't overlap with C features, which means that ObjC is automatically compatible with the latest C standards).

In the end it's not a big deal of course, C and C++ are now entirely different languages and longterm that's for the better. Even the C++ peeps seem to have come to that realization and no longer recommend to "compile C in C++ mode" (like Herb Sutter in 2012 when trying to justify why MSVC had no C99 support: https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...):

    "We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code."

Did you use an LLM to write this comment? (I don't mean this as an accusation, I'm uncertain. I'm just trying to calibrate myself.)

Edit: I should've had more conviction in my instincts, this is slop.

Rust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk.

> committee members who may not use modern C++ in their daily workflows

Are you sure about this one? I don’t know exactly who’s in the committee these days but last I checked they were all hardcore C++ programmers with decades of experience from the trenches.

I don't think that's true? Nothing gets in the standard without substantial actual experience on at least an experimental compiler branch first. It's just not always your compiler.

> Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to catch up.

Eh, all of the committee members I've known are obsessed with modern C++, and "can this feature be implemented?" is definitely a blocker; numerous features got kicked down the road from C++0x to later versions because compilers weren't ready for them.

C++ is a language with perfect 30-year backwards compatibility, and which mostly-maintains compatibility with another language it forked from (C), after 40 years of diverging development.

Rust is a language which isn't backwards-compatible, and certainly not compatible with source code in other languages.

Now, sure, Rust has its advantages, but - how can you fault C++ in the context of compatibility?

This is so true and it's a danger for other ecosystems too. Once the big corporations throw their weight in (be it in a committee or only informally) they make their use cases dominant regardless how niche they might be for the rest of the world.

For example in Rust there is one big entity that currently pours a lot of energy into improving C++ interop. Now, this is not exactly a niche topic, but especially in a world where AI makes many rewrites possible that we wouldn't have daunted to think about a couple of years before, we shouldn't waste too much effort to save legacy companies enormous codebases at the detriment of our preferred language.

There is no problem putting objects past the end of another object in C++.

I use this approach as part my zero-copy serialization library for what I call "out-of-line" sequences.

It does require smart usage of std::launder to be standards-compliant though.

Designated initializers were unofficially supported by GCC (and clang IIANM) since around when C++11 was supported. See:

https://godbolt.org/z/3aKaa7dnM

only if you specifically ask to get an error, would you actually get it.

> std::string_view or std::span should be used instead

That is for when the owner is a std::string or an owning range respectively. But a raw pointer does still make sense as a non-owning view over a single element, doesn't it? I'm new to C++ so I might be wrong.

30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.

Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.

I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.

Already in C++98 there were differences.

?: has another execution priority.

Implicit cast scenarios are reduced in C++.

The array at the end of the struct is not a VLA on the stack. When you allocate the struct, you add enough extra to hold the contents of the array. VLAs on the stack are pretty much universally considered a bad idea, as far as I can tell.

You can just run it through a compiler in c++ language mode.