C++ is probably the largest, most complex programming language to ever exist. I, as a former C++ compiler developer, find it hard to keep up with the language changes. What chance does an average user have?
Going from C++11 to 14 and so on... it’s hard to keep up with those changes. And I’m reluctant to use C++—not because C++ is a bad language, but basically because it’s been used so widely, the places I work have a lot of legacy C++ code, and since each version is different, it’s hard to adapt. I know it’s not a feature everyone uses, and I know you have to define your domain according to your work and limit yourself to a subset, but C++ can do too many things, and even within that there are many overlapping ways, so it’s more confusing. When features are added, you do feel pressure to know them, right? In my head I know “C++ should be limited depending on the domain!” but the problem is that using this language means you have to know it—and even in the same domain, C++ has many different ways of doing the same thing, so it’s freeing but painful for maintenance, I think.
Even the author of a well-known series of books about C++ has long since "given up" because the laundry list of footguns, caveats and adversarial interactions between different features has gotten too long.
This contracts design is good, opposed to Gudstedt's variant with the semicolon.
Because here it is trivial to make them backwards compatible, by just using a PRE() and POST() macro which are empty pre-C++26.
The contracts_assert is either static or runtime, which the compiler can decide. Better than explicit static/asserts, which are either unnecessary or costly.
IMHO the current contracts are a half-baked feature that I suspect will immediately end up in most coding styles as "do not use contracts".
I understand the concept but having a feature that's not consistent among compilers, targets, ... all while doing absolutely nothing to solve the _real_ problems with C++. Like that the build model is still the obsolete TU model of C, while adding multiple compile-time features that inevitably end up causing build times to skyrocket considerably. Or that modules are still DOA after 6 years. Or that the syntax is full of bullshit anti-features that could be at least fixed by having a proper build model (like Rust) and editions (like Rust).
Having yet another feature that only works sometimes with quirky semantics is dumb and I understand why many people feel like it should be shelved to prioritise the features people _really_ care about, like meta
I can only describe current C++ as a Frankenstein. Trying to introduce modern features while having to keep compatibility is just really hard and probably not "the right way".
The simplified TLDR is that ISO for the very first time did not approve a proposed C++ standard.
9 out of 22 countries voted "no", six would have been enough.
These were Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain, and Sweden. In a addition and independently only 12 of the 20 participating members approved when 14 were needed.
The dispute is most likely because of a single feature called "contracts".
Very simplified these are conditions placed in a function's signature that are supposed to be checked at runtime.
The proposed implementation of this feature has been controversial from the start with prominent members of the community (Bjarne Stroustrup amongst them) expressing concerns.
“Draft International Standard”, but that doesn’t mean much unless you read how the ISO process works[1]. (It’s like writing “Advanced Encryption Standard” instead of “AES”—unhelpful beyond giving the broadest category to which the thing belongs, “a document” resp. “a cipher”.)
C++ has lost touch with reality a few years ago. Modules, a feature 6 years old still only have partial support [1] and are nowhere to be seen in practical use. Good luck finding g a C++ library using modules.
This may be similar to Java vs Kotlin race, where Kotlin added improvements, while Java was still stuck in 1.8. The answer was to add as many features to the language as possible. Looks a bit like C++ is starting to do the same.
> The answer was to add as many features to the language as possible.
Because Java is losing market to languages with many features. Which is good. Given history of Java under Oracle supervision, and the availability of Rust, Go and C#, I won't ever touch any JRE-based language.
The C++ committee is pointless, and this is coming from a C++ expert.
Most of the things the committee has been "working on" are realistically _side projects_ today with AI. I've made countless additions to my clang fork the most notable being a source compatible borrow checker, ie you turn it on and it tells you where you effed up. Zero source changes. Equally as correct as Rust. For any sane C++ program. The committee still isn't capable of implementing this btw.
Because you want to use particular C or C++ libraries and either writing a wrapper is too daunting or such a wrapper would be awkward to use in your language of choice.
You want to use Qt. Or you're writing for a platform where you have no choice (most microcontrollers for example).
From a language perspective the only one I can think of is that C++ coroutines are much more powerful than what Rust gives you at the moment, even though they are very footgun-dense (quelle surprise).
But yeah, overall there is very little reason to pick C++, especially now it's feasible to translate existing C++ to other languages.
C++ is probably the largest, most complex programming language to ever exist. I, as a former C++ compiler developer, find it hard to keep up with the language changes. What chance does an average user have?
Going from C++11 to 14 and so on... it’s hard to keep up with those changes. And I’m reluctant to use C++—not because C++ is a bad language, but basically because it’s been used so widely, the places I work have a lot of legacy C++ code, and since each version is different, it’s hard to adapt. I know it’s not a feature everyone uses, and I know you have to define your domain according to your work and limit yourself to a subset, but C++ can do too many things, and even within that there are many overlapping ways, so it’s more confusing. When features are added, you do feel pressure to know them, right? In my head I know “C++ should be limited depending on the domain!” but the problem is that using this language means you have to know it—and even in the same domain, C++ has many different ways of doing the same thing, so it’s freeing but painful for maintenance, I think.
Even the author of a well-known series of books about C++ has long since "given up" because the laundry list of footguns, caveats and adversarial interactions between different features has gotten too long.
This contracts design is good, opposed to Gudstedt's variant with the semicolon.
Because here it is trivial to make them backwards compatible, by just using a PRE() and POST() macro which are empty pre-C++26.
The contracts_assert is either static or runtime, which the compiler can decide. Better than explicit static/asserts, which are either unnecessary or costly.
IMHO the current contracts are a half-baked feature that I suspect will immediately end up in most coding styles as "do not use contracts".
I understand the concept but having a feature that's not consistent among compilers, targets, ... all while doing absolutely nothing to solve the _real_ problems with C++. Like that the build model is still the obsolete TU model of C, while adding multiple compile-time features that inevitably end up causing build times to skyrocket considerably. Or that modules are still DOA after 6 years. Or that the syntax is full of bullshit anti-features that could be at least fixed by having a proper build model (like Rust) and editions (like Rust).
Having yet another feature that only works sometimes with quirky semantics is dumb and I understand why many people feel like it should be shelved to prioritise the features people _really_ care about, like meta
> the features people _really_ care about
And what are those? You seem to assume that "everyone" (except the committee) is in agreement about them.
I can only describe current C++ as a Frankenstein. Trying to introduce modern features while having to keep compatibility is just really hard and probably not "the right way".
Frankenstein was the scientist. It was his "monster" that was a patchwork of all kinds of things.
That's why the world looks more favorably at Rust than C++ now.
The simplified TLDR is that ISO for the very first time did not approve a proposed C++ standard.
9 out of 22 countries voted "no", six would have been enough. These were Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain, and Sweden. In a addition and independently only 12 of the 20 participating members approved when 14 were needed.
The dispute is most likely because of a single feature called "contracts".
Very simplified these are conditions placed in a function's signature that are supposed to be checked at runtime.
The proposed implementation of this feature has been controversial from the start with prominent members of the community (Bjarne Stroustrup amongst them) expressing concerns.
What does "DIS" mean?
DIS is Draft International Standard, the near-final draft that ISO national bodies vote on before it becomes an official standard.
Also: LEWG is the Library Evolution Working Group.
Draft International Standard (https://committee.iso.org/sites/tc211/home/resolutions/isotc...)
This was the vote to promote the current proposal to draft standard.
“Draft International Standard”, but that doesn’t mean much unless you read how the ISO process works[1]. (It’s like writing “Advanced Encryption Standard” instead of “AES”—unhelpful beyond giving the broadest category to which the thing belongs, “a document” resp. “a cipher”.)
[1] https://www.iso.org/stages-and-resources-for-standards-devel...
DIS NUTS
C++ has lost touch with reality a few years ago. Modules, a feature 6 years old still only have partial support [1] and are nowhere to be seen in practical use. Good luck finding g a C++ library using modules.
This may be similar to Java vs Kotlin race, where Kotlin added improvements, while Java was still stuck in 1.8. The answer was to add as many features to the language as possible. Looks a bit like C++ is starting to do the same.
[1] https://en.cppreference.com/cpp/compiler_support
> The answer was to add as many features to the language as possible.
Because Java is losing market to languages with many features. Which is good. Given history of Java under Oracle supervision, and the availability of Rust, Go and C#, I won't ever touch any JRE-based language.
Old king is still fighting but rust is just more properly for agent powered missions
The C++ committee is pointless, and this is coming from a C++ expert.
Most of the things the committee has been "working on" are realistically _side projects_ today with AI. I've made countless additions to my clang fork the most notable being a source compatible borrow checker, ie you turn it on and it tells you where you effed up. Zero source changes. Equally as correct as Rust. For any sane C++ program. The committee still isn't capable of implementing this btw.
As a C++ you should know that the C++ committee is not responsible for implementing features.
> Equally as correct as Rust.
Doubt.
What a mess. Can anyone give me a bull-case for why you would ever pick C++ for a new project?
Because you want to use particular C or C++ libraries and either writing a wrapper is too daunting or such a wrapper would be awkward to use in your language of choice.
You want to use Qt. Or you're writing for a platform where you have no choice (most microcontrollers for example).
From a language perspective the only one I can think of is that C++ coroutines are much more powerful than what Rust gives you at the moment, even though they are very footgun-dense (quelle surprise).
But yeah, overall there is very little reason to pick C++, especially now it's feasible to translate existing C++ to other languages.