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, aka "Typescript for 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.
This is already a good norm. A substantial portion of the new language features really aren't meant for business logic but instead help library developers anyway.
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.
The problem with C are the parts that C++ already provides an alternative, regarding bounds checking, generic code with preprocessor tricks or now that _Generic thingie, stronger typed enumerations, heap allocations without sizeof math, automatic resource cleanups.
I would feel the opposite. I dare not write a program in C. The mentality of RAII and destructors for resource management is so ingrained that attempting to track resource use and lifetime in C would be nightmarish.
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 ?
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.
I've never used LLMs for C++ but I notice that it likes to use every available feature on other languages. Is Claude-generated C++ incomprehensible as a result?
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.
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.
Yeah, you're referring to Scott Meyers and he gave a really insightful talk about how complex and inconsistent C++ has become here titled "The Last Thing D Needs":
The conclusion is "The last thing D needs is someone like me." meaning D should avoid designing a language where you basically need a niche of lawyers crawling through the language standard to decipher the meaning of various features and then write about how to safely use those features. It's not that languages shouldn't have experts who give good advice, but that the nature of advice in C++ has come down to explaining arbitrary rules, inconsistencies, and obscure corner cases rather than how to use the language effectively to solve actual problems.
He says at some points (taken from the transcript):
"There are some arbitrary, wacky decisions, in my opinion ... There's a lot of, in my opinion, simple arbitrary choices that did not have to be made that make explaining things more complicated and also make working with the tool more complicated."
"Much too much of what I've written about has been tool use, talking about language idiosyncrasies, arbitrary decisions, things you need to be able to remember."
"There is epicycle on epicycle on epicycle inside this language."
And then he followed it up a few years later with a blog post explaining that he won't be updating his book with language related fixes because he no longer trusts himself to know what's right from what's wrong:
"C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind."
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.
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).
The actual ISO approvals for C++17 and C++23 came in 2018 and 2024 respectively, so it’s pretty likely this will still be called C++26 if it comes out any time in the next three years
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.
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.
Why I have the gut feeling, that this is good for us? Not saying I understand contracts at all. I read about contracts being complex and adding implementation defined behavior. I don’t want that!
C++ needs #secure and #insecure built-in. Kill all undefined-behavior and minimize implementation behavior. Maybe add new library types with default safety. Put the unfixable stuff behind #insecure.
I see immediate benefits of things added in C+11, C++14 and C++17. Basically they made it safer and less error-prone.
From colleagues in various national bodies, it's very political since it's about "taste" for various features rather than e.g. bug fix in the standard which is fundamentally neutral.
Would myself (not in the committee) argue that contracts as is would most probably be relegated to modules support hell in terms of support and implementation variations, and I think it's in everyone's interest not to repeat that.
The fact that contracts allow non pure functions to be called is just begging to be a large source of bugs to be. I think that if they started with pure functions, then in future standards mechanised some way to call non pure functions? Would be better and more accepted.
Just like reflection, instead of being overly encompassing, we were given at least the beginning to something great. (Though I dislike some syntax and utility functions, as well as the bareness of some reflection, e.g. can't reflect on templates, other than is it a template.)
The big reddit thread on/r/cpp might actually be the _most_ prominent public example of how political it is (and how the committee operates in general), with several people involved with WG21 arguing in the open.
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.
People who don't have version control in 2026 are not "everywhere" any more than people who still heat their home with a coal fire, or travel exclusively on horseback. Those people are weird. They do exist, but they're not "everywhere".
Rust is much less common than version control, but so is C++.
I don't think you live anywhere close to the normal world. It's like saying "all my friends have phds". I mean, don't everybody know three languages and basic multivariate calculus?
I don't know about that. If you extend the scope to include Excel spreadsheet users, website designers, illustrators, writers and so on, version control is not common at all. Or they have something but it's a tragicomic parody of version control, such as what MS Word and Google docs provides.
That's a fair point, but now we're back to actually Rust makes better sense than C++ because the difference is much more stark if you're not already a programmer.
Some of the craziest things about C++ metastasised and are now everywhere in programming, so they don't seem as crazy - but if you're a non-programmer they will still be crazy in C++ and Rust doesn't have them.
For example why does "const" mean immutable? In Rust it means constant, like you'd expect. Why is "Hello" six units of storage space? In Rust it's five, because duh. Why does passing this HugeDoodad into a function expensively copy the HugeDoodad? In Rust it doesn't do that.
“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?
> and is no longer undefined behaviour to act on them
This is only partially true. From the proposal [0]:
> Moreover, a variable that has a well-defined, erroneous initial object representation under this proposal can still lead to undefined behaviour later on:
void f(T&);
void g(bool);
void h() {
T* p; // uninitialized, has erroneous value (e.g. null)
bool b; // uninitialized, erroneous value may not be valid bool
f(*p); // dereferencing has undefined behaviour
g(b); // undefined behaviour if b is invalid
}
Unfortunately C++ is full of very dubious features that I argue may not make much sense or may make sense in a different form that's not how C++ implements them.
Except it still drags unsafe legacy APIs into the future as part of its core library. std::env for example isn't some safe take on how to deal with a system provided program environment in a modern multithreaded language, it is a thin wrapper around an ancient C POSIX API that is not threadsafe and cannot be fixed.
Rust can't magically fix how Unix works. On Windows, the unsafe APIs in std::env are merely unsafe, if you use them carefully you're fine. On Unix, these APIs can cause chaos if you use them in multi-threaded context because Unix never provided any mechanism, even in a modern Linux, to do better.
Rust is doing everything it can here, these APIs are labelled unsafe, and on a system where they can work, they will work. You can see similar in the filesystem code. On Windows, or a modern Linux, you get what you'd like to have, and on somebody's SysV clone where that's not possible it's still not possible from Rust.
Rust has no reason to touch the original Unix API. Take a snapshot of the values at startup and write an API around that, any runtime modification of the Unix environment is suspect anyway and anyone who wants to deal with that rotten mess can jump through half a dozen hoops.
> Rust is doing everything it can here, these APIs are labelled unsafe
Unix gave us C, clearly Rust should have just labeled every C standard library function like malloc and free unsafe and thrown up their hands instead of introducing ownership semantics and all that messy compiler logic around it. After all Rust can't fix how Unix works, so they shouldn't have tried in the first place.
Let me clarify. There is no reason for std::env to be dragged down by UNIX, it could be its own, modern, safe thing with the Unix API living in std::pet_cemetary or some comparably clear namespace for people who have to pass runtime information to a C library through absolutely unsafe ways. Environment variables are usefull, the unix limitations make them less so.
It could be a completely separate "modern, safe thing" which roughly nobody has any use for and which would be confusing since what people want are environment variables and this would instead be its own "modern, safe thing" for some reason.
Mutex<HashMap<String,String>> is probably a reasonable "modern, safe thing" for the handful of people who actually would get value out of this, and the fact it's not labelled "Environment variables" because that's not what it is probably also avoids people who needed the actual environment variables cursing because they were hidden down the back of the sofa.
Why not? Is it the lack of race conditions? The lack of crashes or memory leaks? Is it the fact that you came up with it in five seconds and it is still a million times better than what we have? Or is it the fact that the holy book of Posix spells out how to do it badly in C and because of that we are never allowed to replace it with something better?
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.
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.
I think it’s a syndrome that attacks programming language enthusiasts.
C++ is perhaps the worst case, but C and Python also suffer badly. Java, C#, and Swift perhaps too.
Once a language reaches broad adoption, it should be frozen. If you want to make changes, then feel free to call it something else. The only good reason for standards committees is to resolve ambiguities in the initial specification.
It’s a misapplication of skills and interests. Language people want to add new stuff, fix old stuff, and make their language universally applicable. Putting them in charge of the spec is bound to end in a C++ style disaster.
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.
> Or you're writing for a platform where you have no choice (most microcontrollers for example).
I don't get this in particular. All of these devices have C, which seems like a better fit for the problems you'd likely have on a platform that's small or obscure enough that it hasn't got something nicer than C++
In places where you can use C you can just ask easily use C++. It has a number of nice ergonomic improvements that make it a better option than C, though you would typically opt out of exceptions, RTTI, and maybe the standard library.
You can, but I don't think you should. I can see how the ergonomics are appealing for larger software but the value seems very slim on a microcontroller. Of course I'm biased, but I actually think more of this software ought to be in assembler - whereas perhaps you'd expect I believe it should be Rust.
I think when 20% of your code is trying to energize a solenoid or wrangle a temperature sensor and another 20% is trying to make the vendor's awful LCD controller do something useful and not insane you'd be just as happy writing the mnemonics for machine code instructions and you'd spend less time staring at diagnostics trying to guess why it's doing whatever it's doing because your ten year old fork of GCC has a bug.
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)
Sure, but Qt (at least QtWidgets) is still really good, even if it is aging quite badly at this point.
The signal/slot system actually doesn't need MOC anymore, and the custom container classes are pretty obvious.
That said I think some Rust GUI frameworks are finally starting to mature. I quite like gpui-kit (formerly gpui-component). Maybe not as easy to use as Qt but it doesn't matter so much now with AI.
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, aka "Typescript for 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.
This is already a good norm. A substantial portion of the new language features really aren't meant for business logic but instead help library developers anyway.
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.
The problem with C are the parts that C++ already provides an alternative, regarding bounds checking, generic code with preprocessor tricks or now that _Generic thingie, stronger typed enumerations, heap allocations without sizeof math, automatic resource cleanups.
So use a minimal approach to C++.
I would feel the opposite. I dare not write a program in C. The mentality of RAII and destructors for resource management is so ingrained that attempting to track resource use and lifetime in C would be nightmarish.
C++ was complex already 15 years ago (template metaprogramming, anyone?).
Can't imagine what it must be nowadays.
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.
In my experience, many SFINAE use cases have already been replaced by C++17's constexpr-if. Concepts are just the nail in the coffin :)
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 ?
[dead]
Cfront seems so quaint in retrospect.
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.
Thanks!
Sure, but even then each org agrees on a different C++ subset. So each time you switch project you have to learn again.
And then there's the constant fear of UB, which the compiler doesn't tell you about. This language became too painful for me at least a decade ago.
I've never used LLMs for C++ but I notice that it likes to use every available feature on other languages. Is Claude-generated C++ incomprehensible as a result?
The best orgs have style guide that restrict features
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.
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.
Yeah, you're referring to Scott Meyers and he gave a really insightful talk about how complex and inconsistent C++ has become here titled "The Last Thing D Needs":
https://www.youtube.com/watch?v=KAWA1DuvCnQ
Slides are here:
https://www.aristeia.com/TalkNotes/TheLastThingDNeeds2-ups.p...
The conclusion is "The last thing D needs is someone like me." meaning D should avoid designing a language where you basically need a niche of lawyers crawling through the language standard to decipher the meaning of various features and then write about how to safely use those features. It's not that languages shouldn't have experts who give good advice, but that the nature of advice in C++ has come down to explaining arbitrary rules, inconsistencies, and obscure corner cases rather than how to use the language effectively to solve actual problems.
He says at some points (taken from the transcript):
"There are some arbitrary, wacky decisions, in my opinion ... There's a lot of, in my opinion, simple arbitrary choices that did not have to be made that make explaining things more complicated and also make working with the tool more complicated."
"Much too much of what I've written about has been tool use, talking about language idiosyncrasies, arbitrary decisions, things you need to be able to remember."
"There is epicycle on epicycle on epicycle inside this language."
And then he followed it up a few years later with a blog post explaining that he won't be updating his book with language related fixes because he no longer trusts himself to know what's right from what's wrong:
"C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind."
https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...
Assuming you're talking about Scott Meyers, that's a fabrication.
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.
Template meta programming is essential to many kinds of efficiency that are quite tedious to mimic in C.
Aren't C++ templates the desktop version of macros?
Unless I am mistaken macros have been around for ages and are available in many many languages.
In what way is making the program harder to read contrary to making the final program more efficient?
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; };
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
> won’t technically be in C++26 anymore
The actual ISO approvals for C++17 and C++23 came in 2018 and 2024 respectively, so it’s pretty likely this will still be called C++26 if it comes out any time in the next three years
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.
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.
Why I have the gut feeling, that this is good for us? Not saying I understand contracts at all. I read about contracts being complex and adding implementation defined behavior. I don’t want that!
C++ needs #secure and #insecure built-in. Kill all undefined-behavior and minimize implementation behavior. Maybe add new library types with default safety. Put the unfixable stuff behind #insecure.
I see immediate benefits of things added in C+11, C++14 and C++17. Basically they made it safer and less error-prone.
Isn't it kinda ... obvious? It may not be as bad as modules/reflection/std::range/std::execution, but it's still a bag of UB shits.
Went looking on reddit and other places for a good, non-political explanation of what's going on. Didn't find that, but I did find this good critique of contracts by david_chisnall: https://lobste.rs/s/rlrfew/balloting_has_completed_for_c_26#...
From colleagues in various national bodies, it's very political since it's about "taste" for various features rather than e.g. bug fix in the standard which is fundamentally neutral.
Would myself (not in the committee) argue that contracts as is would most probably be relegated to modules support hell in terms of support and implementation variations, and I think it's in everyone's interest not to repeat that.
The fact that contracts allow non pure functions to be called is just begging to be a large source of bugs to be. I think that if they started with pure functions, then in future standards mechanised some way to call non pure functions? Would be better and more accepted.
Just like reflection, instead of being overly encompassing, we were given at least the beginning to something great. (Though I dislike some syntax and utility functions, as well as the bareness of some reflection, e.g. can't reflect on templates, other than is it a template.)
The big reddit thread on/r/cpp might actually be the _most_ prominent public example of how political it is (and how the committee operates in general), with several people involved with WG21 arguing in the open.
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.
This is an exaggeration.
For me, C+11/C++14 made the language much more approachable and readable.
It was only that from then on, the language was to be updated regularly.
> Good luck finding g a C++ library using modules
There are, surprisingly, quite a few, including some very high-profile ones.
https://arewemodulesyet.org/projects/
> 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.
Great, that means fewer bloated JVM based products will be released as well.
Only on Hacker News. In the real world Java and C++ are absolutely everywhere and no one uses Rust.
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.
People who don't have version control in 2026 are not "everywhere" any more than people who still heat their home with a coal fire, or travel exclusively on horseback. Those people are weird. They do exist, but they're not "everywhere".
Rust is much less common than version control, but so is C++.
I don't think you live anywhere close to the normal world. It's like saying "all my friends have phds". I mean, don't everybody know three languages and basic multivariate calculus?
I don't know about that. If you extend the scope to include Excel spreadsheet users, website designers, illustrators, writers and so on, version control is not common at all. Or they have something but it's a tragicomic parody of version control, such as what MS Word and Google docs provides.
That's a fair point, but now we're back to actually Rust makes better sense than C++ because the difference is much more stark if you're not already a programmer.
Some of the craziest things about C++ metastasised and are now everywhere in programming, so they don't seem as crazy - but if you're a non-programmer they will still be crazy in C++ and Rust doesn't have them.
For example why does "const" mean immutable? In Rust it means constant, like you'd expect. Why is "Hello" six units of storage space? In Rust it's five, because duh. Why does passing this HugeDoodad into a function expensively copy the HugeDoodad? In Rust it doesn't do that.
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”, 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...
Draft International Standard (https://committee.iso.org/sites/tc211/home/resolutions/isotc...)
This was the vote to promote the current proposal to draft standard.
[flagged]
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 like the editions idea. We could have a memory-safe C++ successor without being weighed down by old mistakes.
> And what are those?
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?
Hopefully we will get P1729R5 in 29.
But then input handling is much more complex than output handling.
Also, 26 now initialises trivial variables with erroneous values, and is no longer undefined behaviour to act on them.
> and is no longer undefined behaviour to act on them
This is only partially true. From the proposal [0]:
> Moreover, a variable that has a well-defined, erroneous initial object representation under this proposal can still lead to undefined behaviour later on:
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...Fair.
<meta> is the feature people really care about.
We have one. It's called Rust.
Sadly it misses many features in C++, it's not really a replacement:(
Any C++ replacement language should support all the features of C++ to be suitable...
Unfortunately C++ is full of very dubious features that I argue may not make much sense or may make sense in a different form that's not how C++ implements them.
C++'s features are the reason everyone hates it.
Except it still drags unsafe legacy APIs into the future as part of its core library. std::env for example isn't some safe take on how to deal with a system provided program environment in a modern multithreaded language, it is a thin wrapper around an ancient C POSIX API that is not threadsafe and cannot be fixed.
Rust can't magically fix how Unix works. On Windows, the unsafe APIs in std::env are merely unsafe, if you use them carefully you're fine. On Unix, these APIs can cause chaos if you use them in multi-threaded context because Unix never provided any mechanism, even in a modern Linux, to do better.
Rust is doing everything it can here, these APIs are labelled unsafe, and on a system where they can work, they will work. You can see similar in the filesystem code. On Windows, or a modern Linux, you get what you'd like to have, and on somebody's SysV clone where that's not possible it's still not possible from Rust.
> Rust can't magically fix how Unix works.
Rust has no reason to touch the original Unix API. Take a snapshot of the values at startup and write an API around that, any runtime modification of the Unix environment is suspect anyway and anyone who wants to deal with that rotten mess can jump through half a dozen hoops.
> Rust is doing everything it can here, these APIs are labelled unsafe
Unix gave us C, clearly Rust should have just labeled every C standard library function like malloc and free unsafe and thrown up their hands instead of introducing ownership semantics and all that messy compiler logic around it. After all Rust can't fix how Unix works, so they shouldn't have tried in the first place.
> Rust has no reason to touch the original Unix API.
As a systems language, Rust must provide access to the APIs of the underlying system, and on UNIX, that’s, well, UNIX.
> and on UNIX, that’s, well, UNIX.
Let me clarify. There is no reason for std::env to be dragged down by UNIX, it could be its own, modern, safe thing with the Unix API living in std::pet_cemetary or some comparably clear namespace for people who have to pass runtime information to a C library through absolutely unsafe ways. Environment variables are usefull, the unix limitations make them less so.
> it could be its own, modern, safe thing
It could be a completely separate "modern, safe thing" which roughly nobody has any use for and which would be confusing since what people want are environment variables and this would instead be its own "modern, safe thing" for some reason.
Mutex<HashMap<String,String>> is probably a reasonable "modern, safe thing" for the handful of people who actually would get value out of this, and the fact it's not labelled "Environment variables" because that's not what it is probably also avoids people who needed the actual environment variables cursing because they were hidden down the back of the sofa.
> because that's not what it is
Why not? Is it the lack of race conditions? The lack of crashes or memory leaks? Is it the fact that you came up with it in five seconds and it is still a million times better than what we have? Or is it the fact that the holy book of Posix spells out how to do it badly in C and because of that we are never allowed to replace it with something better?
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".
It was already (accurately) described as "an octopus made by nailing extra legs onto a dog" around the turn of the millennium.
Frankenstein was the scientist. It was his "monster" that was a patchwork of all kinds of things.
But "a Frankenstein" could be his work, like "a Picasso".
"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.
Only Rube Goldberg can make a Rube Goldberg machine?
"Machine" is the keyword here. Just like you'd say "a Frankenstein monster", not "a Frankenstein".
That's why the world looks more favorably at Rust than C++ now.
[dead]
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.
I think it’s a syndrome that attacks programming language enthusiasts.
C++ is perhaps the worst case, but C and Python also suffer badly. Java, C#, and Swift perhaps too.
Once a language reaches broad adoption, it should be frozen. If you want to make changes, then feel free to call it something else. The only good reason for standards committees is to resolve ambiguities in the initial specification.
It’s a misapplication of skills and interests. Language people want to add new stuff, fix old stuff, and make their language universally applicable. Putting them in charge of the spec is bound to end in a C++ style disaster.
Old king is still fighting but rust is just more properly for agent powered missions
What a mess. Can anyone give me a bull-case for why you would ever pick C++ for a new project?
A never-ending list of security issues that you need to fix, thus a steady stream of contractor income.
One of the easiest ways to generate passive income.
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.
> Or you're writing for a platform where you have no choice (most microcontrollers for example).
I don't get this in particular. All of these devices have C, which seems like a better fit for the problems you'd likely have on a platform that's small or obscure enough that it hasn't got something nicer than C++
In places where you can use C you can just ask easily use C++. It has a number of nice ergonomic improvements that make it a better option than C, though you would typically opt out of exceptions, RTTI, and maybe the standard library.
You can, but I don't think you should. I can see how the ergonomics are appealing for larger software but the value seems very slim on a microcontroller. Of course I'm biased, but I actually think more of this software ought to be in assembler - whereas perhaps you'd expect I believe it should be Rust.
I think when 20% of your code is trying to energize a solenoid or wrangle a temperature sensor and another 20% is trying to make the vendor's awful LCD controller do something useful and not insane you'd be just as happy writing the mnemonics for machine code instructions and you'd spend less time staring at diagnostics trying to guess why it's doing whatever it's doing because your ten year old fork of GCC has a bug.
> I actually think more of this software ought to be in assembler - whereas perhaps you'd expect I believe it should be Rust.
Yes obviously. Or potentially Zig once it is more stable.
Doing it in assembly in 2026 is absurd.
For most microcontrollers you'd want to use today (ARM and RISC-V mostly, Xtensa or AVR if you like pain) you can just use Rust.
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.
> You want to use Qt
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)
C++32’s std::ui will solve that.
And then C++38's std::ui2 will solve that.
Sure, but Qt (at least QtWidgets) is still really good, even if it is aging quite badly at this point.
The signal/slot system actually doesn't need MOC anymore, and the custom container classes are pretty obvious.
That said I think some Rust GUI frameworks are finally starting to mature. I quite like gpui-kit (formerly gpui-component). Maybe not as easy to use as Qt but it doesn't matter so much now with AI.