To use the subset that makes it a better alternative than C, aka "Typescript for C", and ignore the rest.

Hopefully we would have moved on into fully bootstraped alternatives, but open source has decided to build their alternative languages on top of LLVM and GCC instead, with some minor exceptions.

Note that I am starting to have a "find it hard to keep up with the language changes" similar feeling with Java, C#, Python and TypeScript.

I have the same opinion. C++ was my first programming language I used at work. I feel that I was relatively proficient with it, but it was around 2005 I think. Since then I've mostly used other languages. Right now I feel I can use C with ease, in fact I periodically use it. But C++? I don't even dare.

I guess it's fine if one specializes on C++ programming only. But when one needs to use different languages and C++ is used sporadically, I feel like it might be substantially harder than other languages.

Extreme accretion/scope-creep of syntax (and features) across all languages continues, C++ is probably one of the most extreme example of this.

Everyone's trying to bring in the shiniest new toys from all other languages. So-called "modern C++" is an unbearable menu of every possible flavor of procedural, functional, OOP, templates, strong/weak typing, metaprogramming, and so much more. End result is a Frankenstein mix of C, Fortran, Pascal, Python, F#, Scala, C#/Java, Visual Basic, LUA, TCL, Rust, and what not... and that's before we even talked about the STL/STD situation in C++.

The only correct way to work with C++ is to agree on the most minimal subset of features needed for consistency and productivity in your codebase, stick to those and avoid adopting 95% of the crap that's being brought in. Ignore the noise.

I've never used LLMs for C++ but I notice that it likes to use every available feature on other languages. Is Claude-generated C++ incomprehensible as a result?

C++ was complex already 15 years ago (template metaprogramming, anyone?).

Can't imagine what it must be nowadays.

The best orgs have style guide that restrict features

Going from C++11 to 14 and so on... it’s hard to keep up with those changes. And I’m reluctant to use C++—not because C++ is a bad language, but basically because it’s been used so widely, the places I work have a lot of legacy C++ code, and since each version is different, it’s hard to adapt. I know it’s not a feature everyone uses, and I know you have to define your domain according to your work and limit yourself to a subset, but C++ can do too many things, and even within that there are many overlapping ways, so it’s more confusing. When features are added, you do feel pressure to know them, right? In my head I know “C++ should be limited depending on the domain!” but the problem is that using this language means you have to know it—and even in the same domain, C++ has many different ways of doing the same thing, so it’s freeing but painful for maintenance, I think.

Even the author of a well-known series of books about C++ has long since "given up" because the laundry list of footguns, caveats and adversarial interactions between different features has gotten too long.

The complexity of C++ lies only in template programming, and it doesn't add any efficiency to the final program—on the contrary, it makes the program harder for other programmers to read.

Technically, you're only learning to mentally unfold multi-level nested templates just to verify how they work, and all for the sake of making the program look small with less boilerplate?

This is complete nonsense. For me, C++ died with the 11 standard.

> won’t technically be in C++26 anymore

The actual ISO approvals for C++17 and C++23 came in 2018 and 2024 respectively, so it’s pretty likely this will still be called C++26 if it comes out any time in the next three years

I think the big contention is yet-another "optional" feature you cannot rely on when C++ security record is so-so with regards to memory safety, and if you for "elegance" put predicates for such into contracts.. it can all go out the window even if you intended for it to be strict.

I think defaulting all assertions to enforce would've been better with an optional soft modifier (ie "soft pre(foo)" ), as it is now it's just always assert in a trenchcoat.

The big reddit thread on/r/cpp might actually be the _most_ prominent public example of how political it is (and how the committee operates in general), with several people involved with WG21 arguing in the open.

DIS is Draft International Standard, the near-final draft that ISO national bodies vote on before it becomes an official standard.

Also: LEWG is the Library Evolution Working Group.

“Draft International Standard”, but that doesn’t mean much unless you read how the ISO process works[1]. (It’s like writing “Advanced Encryption Standard” instead of “AES”—unhelpful beyond giving the broadest category to which the thing belongs, “a document” resp. “a cipher”.)

[1] https://www.iso.org/stages-and-resources-for-standards-devel...

Draft International Standard (https://committee.iso.org/sites/tc211/home/resolutions/isotc...)

This was the vote to promote the current proposal to draft standard.

[flagged]

> the features people _really_ care about

And what are those? You seem to assume that "everyone" (except the committee) is in agreement about them.

I like the editions idea. We could have a memory-safe C++ successor without being weighed down by old mistakes.

> The answer was to add as many features to the language as possible.

This is an exaggeration.

For me, C+11/C++14 made the language much more approachable and readable.

It was only that from then on, the language was to be updated regularly.

> Good luck finding g a C++ library using modules

There are, surprisingly, quite a few, including some very high-profile ones.

https://arewemodulesyet.org/projects/

> The answer was to add as many features to the language as possible.

Because Java is losing market to languages with many features. Which is good. Given history of Java under Oracle supervision, and the availability of Rust, Go and C#, I won't ever touch any JRE-based language.

Frankenstein was the scientist. It was his "monster" that was a patchwork of all kinds of things.

That's why the world looks more favorably at Rust than C++ now.

As a C++ you should know that the C++ committee is not responsible for implementing features.

I think it’s a syndrome that attacks programming language enthusiasts.

C++ is perhaps the worst case, but C and Python also suffer badly. Java, C#, and Swift perhaps too.

Once a language reaches broad adoption, it should be frozen. If you want to make changes, then feel free to call it something else. The only good reason for standards committees is to resolve ambiguities in the initial specification.

It’s a misapplication of skills and interests. Language people want to add new stuff, fix old stuff, and make their language universally applicable. Putting them in charge of the spec is bound to end in a C++ style disaster.

You want to use Qt. Or you're writing for a platform where you have no choice (most microcontrollers for example).

From a language perspective the only one I can think of is that C++ coroutines are much more powerful than what Rust gives you at the moment, even though they are very footgun-dense (quelle surprise).

But yeah, overall there is very little reason to pick C++, especially now it's feasible to translate existing C++ to other languages.

A never-ending list of security issues that you need to fix, thus a steady stream of contractor income.

One of the easiest ways to generate passive income.