The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".

1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.

> 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem.

Now tell me why every OOP codebase I look at has this problem. ;-)

The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.

Ah the beauty of use-after-free and memory corruption issues. /s

Try to find one here: https://github.com/jstimpfle/language

Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it.

As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Sure, I'm just saying that a lot of it is due to unsuitable approaches.

If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

Let me know what problems you find!

I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.