I often feel that when C++ posts come up, the majority of commenters are people who haven't deeply worked with C++, and there's several things people always miss when talking about it:<p>- If you're working in a large C++ code base, you are stuck working with C++. There is no migrating to something like Rust. The overhead of training your engineers in a new language, getting familiar with a new tool chain, working with a new library ecosystem, somehow finding a way to transition your code so it works with existing C++ code and isn't buggy and adapts to the new paradigms is all extremely expensive. It will grind your product's development to a buggy halt. It's a bad idea.<p>- Every time a new set of features (e.g. reflection, concepts, modules, etc.) is released, people bemoan how complicated C++ continues getting. But the committee isn't adding features for the sake of adding features, they're adding features because <i>people are asking for them</i>, they're spending years of their lives writing papers for the committee trying to improve the language so everyone can write better code. What you find horrifying new syntax, I find a great way of fixing a problem I've been dealing with for years.<p>- Yes, it's a gross homunculus of a language. If I could switch our team to Rust without issues, I would in a heartbeat. But this is the beast we married. It has many warts, but it's still an incredible tool, with an amazingly hard working community, and I'm proud of that.
C++ is a monster.<p>The 2026 proposal has some neat ideas (I like the ability for the developer to give a reasons for modifying behavior that may create otherwise cryptic error messages, for instance); but the more things one packs in there, the uglier, bloated the specs, and the more complicated and buggy compilers will be.<p>Once C with Classes was an experimental pre-processor to try out bringing in some Simula ideas into the C world. Today, C++ has become a language that changes dramatically every half a decade, where the main question is "will it
compile" if you receive someone else's code, and where even experienced
developers cannot tell from compiler error messages what's wrong (g++). The undoubtedly clever people who have been working on it have nevertheless committed war crimes in anti-orthogonality.<p>Tip: introduce a versioning mechanism like Rust has it, so that you are freed from the burden of having to be backwards-compatible.
Exciting as it may be, to be fully available for portable codebases maybe around 2030, given the current velocity of compilers adoption of ongoing standards, even among the big three.<p>As of today, C++17 is the latest one can aspire to use for portable code, and better not making use of parallel STL features.
One major gripe I have with these C++ updates is that the proportion of codebases that <i>actually use</i> recent C++ features (cpp17, cpp20, cpp23) is very close to zero. The more and more esoteric this language becomes, the fewer people who can actually master it.<p>Source: I've been writing C++ for 8 years.
> if (auto [to, ec] = std::to_chars(p, last, 42))<p>I'm not into plusplus, however i'm curious. How the tuple get evaluated to a condition ? is that lowered to if `to && ec` ?
User-generated static_assert messages would make it easier to build games that can be played entirely using compiler error messages. Something like this old IOCCC entry but nicer:<p><a href="https://www.ioccc.org/years.html#1994_westley" rel="nofollow">https://www.ioccc.org/years.html#1994_westley</a>
This doesn't mention the most exciting thing coming: static reflection. Finally no need to manually implement printing or serialisation functions for every struct.
C++ is a funny chimeric creation that has absorbed some great modern ideas from Rust and other new language but needs to preserve compatibility with its antediluvian C heritage. You could write it in a very clean and somewhat safe modern style or in a familiar C-like style. We use modern C++ at work and, by embracing RAII, it really isn't so bad.
<a href="https://web.archive.org/web/20240907061007/https://mariusbancila.ro/blog/2024/09/06/whats-new-in-c26-part-1/" rel="nofollow">https://web.archive.org/web/20240907061007/https://mariusban...</a><p>It seems to be down.
I for one started working on a new project in C++ rather than Rust. I think it's unclear whether Rust is going to be the successor at this point. It's probably never going to pick up in the games industry, QT is C++ (and Rust bindings will always be second class or they could end up unmaintained), has better compile times and is said to be undisputed when it comes to high performance. Obviously the tool for the job factor is most critical.<p>Career wise, many people are picking up Rust and almost no one is picking up C++, while experienced C++ devs either retire or switch to a higher level language due to landscape change. I would trust supply and demand to be in favour of C++ 10 years from now.<p>There are also attempts to make C++ more memory safe like Carbon[1] or Circle compiler [2]. If they succeed, why would anyone want to switch to Rust? Also Rust is not ideal for security from a different perspective - I think the lack of a package manager is one C++ strongest points. After working for 9 years with npm, you really appreciate that the dependency you install is usually just a single dependency (even an option for a single header file is common), when there's a package manager, people will abuse it (like install a package with 3 dependencies of its own for something that could be 50 LOC copy-paste) and managing the security of the supply chain is nearly impossible (it will be a legal requirement soon in EU though).<p>Anyway, I wanted to ask. How is the contracting market looking in C++ world? I'm guessing it depends on the domain heavily? I'm mainly asking about QT and anything that would be desktop / mobile apps / systems programming except video games, but I'm curious in general.<p>[1] <a href="https://github.com/carbon-language/carbon-lang">https://github.com/carbon-language/carbon-lang</a><p>[2] <a href="https://github.com/seanbaxter/circle">https://github.com/seanbaxter/circle</a>
Leading with "Specifying a reason for deleting a function" then following up with "Placeholder variables with no name" did make me check the date of the article. It wasn't April 1.<p>The standards committee are thorough in their mission to including everything and the kitchen sink in C++.