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?
To use the subset that makes it a better alternative than C, and ignore the rest.
Hopefully we would have moved on into fully bootstraped alternatives, but open source has decided to build their alternative languages on top of LLVM and GCC instead, with some minor exceptions.
Note that I am starting to have a "find it hard to keep up with the language changes" similar feeling with Java, C#, Python and TypeScript.
I have the same opinion. C++ was my first programming language I used at work. I feel that I was relatively proficient with it, but it was around 2005 I think. Since then I've mostly used other languages. Right now I feel I can use C with ease, in fact I periodically use it. But C++? I don't even dare.
I guess it's fine if one specializes on C++ programming only. But when one needs to use different languages and C++ is used sporadically, I feel like it might be substantially harder than other languages.
Extreme accretion/scope-creep of syntax (and features) across all languages continues, C++ is probably one of the most extreme example of this.
Everyone's trying to bring in the shiniest new toys from all other languages. So-called "modern C++" is an unbearable menu of every possible flavor of procedural, functional, OOP, templates, strong/weak typing, metaprogramming, and so much more. End result is a Frankenstein mix of C, Fortran, Pascal, Python, F#, Scala, C#/Java, Visual Basic, LUA, TCL, Rust, and what not... and that's before we even talked about the STL/STD situation in C++.
The only correct way to work with C++ is to agree on the most minimal subset of features needed for consistency and productivity in your codebase, stick to those and avoid adopting 95% of the crap that's being brought in. Ignore the noise.
Sorry for the nitpick, but ossification means the opposite of how you're using it here. It means existing structures / practices becoming frozen in place, by analogy with real ossification which is where flexible cartilage hardens into rigid bone.
It's a very complex language, but I also find little reason in using any of its more niche features; however, I essentially just write C with RAII and templates when it comes to C++, so I'm probably abnormal.
For instance, I can now avoid SFINAE in C++20 and beyond, which was always the ugliest part of C++ templates to me. C++20 concepts simplified most of my metaprogramming needs.
Reading boost libraries was like reading brainfuck. In fact most of std lib source felt that way too. I never reflected on this since I stopped doing C++ 15 years ago - but yeah I have not worked with a language that's worse to read since. Maybe macro heavy lisp ?
The complexity of C++ lies only in template programming, and it doesn't add any efficiency to the final program—on the contrary, it makes the program harder for other programmers to read.
Technically, you're only learning to mentally unfold multi-level nested templates just to verify how they work, and all for the sake of making the program look small with less boilerplate?
This is complete nonsense. For me, C++ died with the 11 standard.
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.
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.
This may not invalidate your point, but C++11 was a major step forward that, for me, made C++ feel much more convenient and modern than before. And C++14 is basically just adding/fixing stuff that should have been in C++11 in the first place.
I like C++11 too. (My introductory book was on C++11 as well—yes, it’s that book about modern C++11.) But some projects require C++14, and other times I have to use C++98.
I’m a “traveling programmer” in Korea. But when I go out to a work site because they say I have to work on C++, as you know, there are so many versions that it’s painful.
Oh my, here I'm looking like a fool, literally gave a talk on the new <meta>/Reflection feature on Thursday and doing it assumed that it was more or less a lock (Well I guess the refl feature will come out if contracts can be dumped and the standard gets out even if it won't technically be in C++26 anymore :P )
The reflection feature is good, I would've settled for less but there's some pretty cool stuff enabled by it.
- direct to struct JSON parsing with property-name aliasing via annotations
- field creation/renaming, I've made a make_named<"a","b">(1,"hello") to create an object with fields named a and b (think of std::make_tuple on steroids)
- I'm basically halfway done with a DB abstraction that can be used similarly to C#'s Linq.
struct [[=sql26::name("posts")]] post { int id; std::string name; };
^- in the above example the template inclusion of post creates the posts-field in the context, the where predicate lambda gets a decorated variant of the post type members that are then deferred until execution (starting iterating the itererable).
It's dangerously powerful though since all of this is enabled by consteval, so any IDE support will need to be running the consteval code continiously in these scenarios to update type-info before being able to do code completion (even if people are probably way into LLM's to bother anymore?).
The talk isn't online yet since they haven't had time to edit the videos.
The JSON and make_named example/code can be found in my repo, haven't pushed the SQL feature yet as I'm not happy with some other parts of the API surface yet (aggregation is hard to express/translate compactly and unambigiously).
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".
"a" would suggest that there was more than one. True for Picasso, not for Frankenstein. Besides, only Picasso can make "a Picasso". Everything else would be fake and plagiarism.
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.
I think the big contention is yet-another "optional" feature you cannot rely on when C++ security record is so-so with regards to memory safety, and if you for "elegance" put predicates for such into contracts.. it can all go out the window even if you intended for it to be strict.
I think defaulting all assertions to enforce would've been better with an optional soft modifier (ie "soft pre(foo)" ), as it is now it's just always assert in a trenchcoat.
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.
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.
This. The discussions on this site are typically oblivious to this fact. I am desperately trying to persuade a corporate client to adopt version control and here people are talking about Rust. It's like we are living on different planets.
“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”.)
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'd start with the basics: A scanf() replacement would be nice, having a ostream/printf() alternative, but not something for input feels very unfinished.
Basic Unicode support is also still a mess.
Another thing I don't get: Why is uninitialized memory still the default? Why haven't they made the uninitialized state explicit in any of the numerous language updates?
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.
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.
But isn't using Qt like learning a whole new layer of language on top of C++, the meta compiler, signal/slot system etc and then Qt have its own set of standard classes like QString (instead of using std::string)
Hopefully we would have moved on into fully bootstraped alternatives, but open source has decided to build their alternative languages on top of LLVM and GCC instead, with some minor exceptions.
Note that I am starting to have a "find it hard to keep up with the language changes" similar feeling with Java, C#, Python and TypeScript.
I guess it's fine if one specializes on C++ programming only. But when one needs to use different languages and C++ is used sporadically, I feel like it might be substantially harder than other languages.
Everyone's trying to bring in the shiniest new toys from all other languages. So-called "modern C++" is an unbearable menu of every possible flavor of procedural, functional, OOP, templates, strong/weak typing, metaprogramming, and so much more. End result is a Frankenstein mix of C, Fortran, Pascal, Python, F#, Scala, C#/Java, Visual Basic, LUA, TCL, Rust, and what not... and that's before we even talked about the STL/STD situation in C++.
The only correct way to work with C++ is to agree on the most minimal subset of features needed for consistency and productivity in your codebase, stick to those and avoid adopting 95% of the crap that's being brought in. Ignore the noise.
Can't imagine what it must be nowadays.
For instance, I can now avoid SFINAE in C++20 and beyond, which was always the ugliest part of C++ templates to me. C++20 concepts simplified most of my metaprogramming needs.
Technically, you're only learning to mentally unfold multi-level nested templates just to verify how they work, and all for the sake of making the program look small with less boilerplate?
This is complete nonsense. For me, C++ died with the 11 standard.
I’m a “traveling programmer” in Korea. But when I go out to a work site because they say I have to work on C++, as you know, there are so many versions that it’s painful.
The reflection feature is good, I would've settled for less but there's some pretty cool stuff enabled by it.
- direct to struct JSON parsing with property-name aliasing via annotations
- field creation/renaming, I've made a make_named<"a","b">(1,"hello") to create an object with fields named a and b (think of std::make_tuple on steroids)
- I'm basically halfway done with a DB abstraction that can be used similarly to C#'s Linq.
struct [[=sql26::name("posts")]] post { int id; std::string name; };
dbcontext<post> dbctx;
for(auto post:dbctx.posts.where([](auto post) { return post.id>100; }) { ... }
^- in the above example the template inclusion of post creates the posts-field in the context, the where predicate lambda gets a decorated variant of the post type members that are then deferred until execution (starting iterating the itererable).
It's dangerously powerful though since all of this is enabled by consteval, so any IDE support will need to be running the consteval code continiously in these scenarios to update type-info before being able to do code completion (even if people are probably way into LLM's to bother anymore?).
The talk isn't online yet since they haven't had time to edit the videos.
The JSON and make_named example/code can be found in my repo, haven't pushed the SQL feature yet as I'm not happy with some other parts of the API surface yet (aggregation is hard to express/translate compactly and unambigiously).
https://github.com/whizzter/ret26
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.
I think defaulting all assertions to enforce would've been better with an optional soft modifier (ie "soft pre(foo)" ), as it is now it's just always assert in a trenchcoat.
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.
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
There are, surprisingly, quite a few, including some very high-profile ones.
https://arewemodulesyet.org/projects/
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.
Also: LEWG is the Library Evolution Working Group.
This was the vote to promote the current proposal to draft standard.
[1] https://www.iso.org/stages-and-resources-for-standards-devel...
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
And what are those? You seem to assume that "everyone" (except the committee) is in agreement about them.
I like the editions idea. We could have a memory-safe C++ successor without being weighed down by old mistakes.
I'd start with the basics: A scanf() replacement would be nice, having a ostream/printf() alternative, but not something for input feels very unfinished.
Basic Unicode support is also still a mess.
Another thing I don't get: Why is uninitialized memory still the default? Why haven't they made the uninitialized state explicit in any of the numerous language updates?
Any C++ replacement language should support all the features of C++ to be suitable...
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.
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.
For anything weirder than that (PIC?) where Rust is no option, it's not like you have no choice either: You can just pick C.
But isn't using Qt like learning a whole new layer of language on top of C++, the meta compiler, signal/slot system etc and then Qt have its own set of standard classes like QString (instead of using std::string)
One of the easiest ways to generate passive income.