[wavemode]

> decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software

How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011?

If you've worked on a project built entirely on the technologies and principles of modern C++, and found that it caused your software to be low-quality, then by all means share those experiences. C++ has no shortage of problems, there is no doubt. But hand-waving about "decades" of nondescript problems other people have had with older C++ versions, is somewhat of a lazy dismissal of the article's central thesis.

[simonask]

> How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011?

Please read the sentence you're quoting again.

[wavemode]

I've read it. If you have a response then say what you're trying to say.

[simonask]

My criticism is not of any particular feature in C++ (though there is much to both hate and love about it), but of a particular approach to software engineering that the language design leans into, and which even the newest iterations of the language do nothing to alleviate, and in many many cases even reinforce.

The easiest path in C++ is almost always the dangerous path. (The classic example is operator[] versus at().) With every tiny feature of the language, things we take fully for granted in every other language, there is a host of caveats, gotchas, footguns, and trap doors.

This is as serious risk as a project and its team grows, because the accumulated sum of accidental complexity grows exponentially.

It’s possible to manage this risk, but it is also expensive, and every modern-ish competitor to C++ allows fewer people to deliver better software quicker.

It’s not a good choice for almost anything that doesn’t specifically require C++ for its own sake.

[germandiago]

Read my comment above: hardening is in, an effort to classify and remove UB is on the way. Implicit contracts (yes, that means basically to bounds-check even native arrays automatically) is on the way.

If you use warnings as errors they catch even subsets of dangling nowadays. Other ways of dangling have been made illegal (temporary conversions and range for lifetime extension).

I agree with you the defaults are still not the best but it is dteafily getting better.

But I think in the next years things are going to be tightened further in standard terms for better defaults. In fact, it is already happening.

The difficult part I think it is lifetimes.

[simonask]

All of that is great, and I strongly support these initiatives, but they are all teeny tiny bandaids.

Lifetimes are a crucial aspect of writing code in C++, yet they do not appear anywhere in the syntax. The same goes for synchronization. These problems are fundamentally unfixable without major, incompatible language changes.