31–40 of 89 posts
I think that the steering committee currently considers that backwards compatibility has higher priority compared to strict memory safety. When the priorities will inverse then solutions will be found.
Earlier quoted context omitted.
I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership. I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-to…
>C++26 is also a joke imho. C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
Earlier quoted context omitted.
I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership. I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-to…
> it was also a mess of intricate object ownership Not much has changed, though, it still is. Just with a lot more bells and whistles around it
> “We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” But the major players do seem to be happy to replace their C++ code wi…
Alas, C++ still mostly does its libraries via conceptual copy-and-paste (#include). So that would need to be fixed, if you wanted to mix-and-match dialects. You could probably keep '#include' syntax, but subtly change its meaning.
Earlier quoted context omitted.
>C++26 is also a joke imho. C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.
The other major problem for C++ is that correct C++ basically looks like nonsense, because the committee insists on pushing dangerous footguns that nobody sane would ever use in normal codebases through yet takes their sweet time with adding basic functionalities like pattern matching or even "print", which is somehow finally added in C++23. Worse still, nothing is ever really allowed to be removed/deprecated from C++, so you have decades of accumulated syntax debt that nobody is allowed to actually fix.
I think the biggest issue with C++ is that despite the fact that 90% of the language just should not be used in any normal code, period, there really is nothing that can replace C++ in its niche of high performance, low-level systems level programming. There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it.
In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…
Carbon?
I think that the steering committee currently considers that backwards compatibility has higher priority compared to strict memory safety. When the priorities will inverse then solutions will be found.
When they inverse the priority, there are little reason to keep on using C++.
Even in those domains there are efforts to do things in Rust, although it's unclear when Rust is going to be an actually serious/viable option.
I suspect C++ will become less of a "mainstream" language but only relevant in those specific domains. OS / Services will consider alternatives first.
In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…
> There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it. Carbon?
In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…
Well.. "C".. though I wouldn't go so far as to call that a good language, either.