Nobody Understands C++: Intro (2007)

I went from "c++ fondness" to "c++ distaste" over the years. The newest c++ standards fix a lot of issues, but at the same time increase complexity. The backwards-compatibility nature is the classic double-edged sword. If we could avoid it, c++ would be at least significantly nicer (not really less complex).

That being said, a good team using a dab of c++ will beat "high quality C" any time of the year for me. Getting away from the preprocessor alone is huuuuuuuge. Everybody complains about memory safety, and the truth is that with even the dumbest string/buffer class it's actually pretty trivial to do the right thing. c++ _does_ really fix most of the c issues IMHO.

A big problem IMHO is that we "learned" to use c++ properly late. The newest standard revisions came late. The feature abuse it receives is still somewhat rampant, and yes a newcomer to c++ would probably find a use for every single feature in a simple usage scenario.

Reading large c++ codebases is hard due to the intermixing of old/new and simply different styles. It has a huge cognitive load, and that is my primary reason for the growing distaste: I want code to be clear and coherent. I can take the complexity if that's used consistently, but it can change massively between even just PARTS of a project.

I won't argue that the first example is cleaner, but both seemingly simple examples have a major issue. Lifetime.

The observer pattern is notorious for being overly complicated in C++ because you have to ensure Observer and Observable keep valid references to each other.

"Modern C++" (what ever that is nowadays) leverages RAII (i.e. scope-based resource management) to improve upon the situation.

With your typical observer (i.e. signal/slots) library you get a "scoped connection" object when registering the callback function. You store that object in your class and when it is destroyed, it breaks the connection. Furthermore, it facilitates the implementation of correct copy and move semantics.

It's not that people don't "understand" C++, the problem is that there are so so many things to watch out for, even in simple use-cases, that even experienced C++ programmers make mistakes on a regular basis.

C++ is very frightened of breaking existing code, including at the binary level. Some shared library built in 2007 stands a decent chance of running today if it avoided the ABI break of ruin and disaster where string and list changed slightly.

It's also widely considered a very complicated language and there's some worry it suffers in user acquisition as a result.

If you take those two properties together, the game plan of making the language look nicer without changing how it works is about all you've got. It accretes more stuff with a bias towards making some use case look nicer.

It leaves margin for faster code below it because slow choices are forever. More syntax over the same operations is a dubious interpretation of making things simpler.

Yet it lives on. People start new projects in it. Some people think the economics work out in favour.

Oh, and some people did understand it in 2007. Maybe only five but they did exist. Some of those may still be heavily involved enough to understand the current language, but I wouldn't be shocked if they're burned out and gone. We might be down to zero.

> It has a huge cognitive load

This. Its like trying to keep three distinct languages (C, old C++, new C++) in one's head at the same time. It is much better use of one's mental energy to spend that effort on three actually distinct languages that are, e.g., tuned to different domains and use cases.

Imho the C++ community needs to address this or eventually become irrelevant as people gravitate to more sane and user-friendly ecosystems. Not sure how that can be done without breaking some eggs. My preference would be for a simplified and streamlined C+++ that tackles this complexity head on.

> Some shared library built in 2007 stands a decent chance of running today if it avoided the ABI break of ruin and disaster where string and list changed slightly.

At least with the default standard library implementation on Linux you can still select which version of these classes are used by setting the __GLIBCXX_USE_CXX11_ABI (or something similar) define. Both versions of these classes are still present in the implementation. So the old library can still be used despite that change.