C++ is, should be, like COBOL. A very important language because of the installed base. But why the continual enhancements? Surely there are better uses of all those resources?
As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.
Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.
It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.
Although there are excellent alternatives to C++ such as Rust, C++ is still widely used as many open-source and commercial codebases are built with it.
Adding features to a language that is still actively used does not seem like a bad thing.
The amount of C++ written at my company every day is… a lot. We are slowly fighting away from it towards memory safety, but it is hard. It will take a decade.
At the company I currently work for we also use C++, and I am quite proficient in it. But the amount of times I have slowed myself down by simple lifetime issues makes me want to switch to a more memory safe language. Whether that is C++ with profiles or a whole new language such as Rust.
For example, a week back I lost a few hours finding a segfault bug in C++ code, which ended up being a trivial lifetime error: I used a reference after it was invalidated due to a std::vector resize.
These kind of errors should be compile time errors, rather than hard to trace runtime errors.
How does your company go about changing to memory safety? Are new projects / libraries written in Rust for example? Do projects / libraries get (partially) rewritten?
It is very hard to reason about lifetimes and they can eat you. We have a lot of guidelines and strategies to simplify it, but it still just isn’t amazing.
Not exactly. There's a lot of C++ code that still can't be rewritten into cool languages overnight without risking correctness, performance and readability.
I'm always happy to see C++ pushing itself and the compiler backends as it benefits the victims of lame codebases and also the cool kids using the improved compiler backends.
I definitely had my eyes on slint for quite some time (pretty much since it was announced - I highly value the technical skill of their team) but it's still quite far from the whole QWidget offering.
I don't know anything else that is even remotely in the same ballpark - certainly not Tauri or egui for instance. Anything that is GPU based is blacklisted from the get go (including QtQuick) - people who preach gpu based GUI have definitely never tried to have a quick debug feedback loop with an app built using AddressSanitizer where just opening the simplest GL or Vulkan context takes up to 20 seconds on a good day.
Only the GUI part is relevant for this discussion as this is what Qt is know for.
Other modules also have different Rust crates equivalent, or are really niche and nobody uses them.
Qt's value is as an app framework where you can assume interoperation across the same async runtime and enjoy a cohesive set of APIs for all your app's needs.
C++ is, should be, like COBOL. A very important language because of the installed base. But why the continual enhancements? Surely there are better uses of all those resources?