1. a well-tested language
2. can not use garbage collector due to *performance* requirement
3. easy to hire if project expands.
4. ready to use tooling support
5. widely available tutorials and info on the web.
6. language is itself alive and updated
7. project can be scaled over time.
Javascript for the web, Python for machine learning, C for low level and system coding, Go for some native cloud and DevOps, Java for enterprise or Android, C# if you're a windows developer, Swift if you are doing Apple, we actually don't have a lot of choices when you need deliver things faster.
I played with nim, ziglang and Rust, but it's hard to use them for real product developments at this point for me.
> ready to use tooling support
This really depends on the use case. If the tooling you're looking for is "Unreal Engine", then Rust is definitely not there yet. But if you want to write network services, databases, CLI tools, etc., I think Rust has been fully viable with good tooling and library support for years now.
> easy to hire if project expands
No doubt hiring experienced Rust developers is hard, because there aren't that many yet. But anecdotally, training Rust developers is much easier than training C++ developers. Rust makes it easier for one or a few experienced folks to have confidence that a larger number of less experienced contributors aren't introducing stability or security issues.
Picking Java over kotlin for android, or lumping C# into "just for windows" bucket is exactly the ignorance that leads you to "we don't have choices" conclusion. If you always default to literally top1 language for given domain, then how can you expect to have multiple choices?
I'm not talking about using some brand new gimmick that came out yesterday and will die tomorrow, but if you aren't able to leave your comfort zone even just-so slightly to update your stereotypes about given given domain and its trends, then by definition you won't see the alternatives.
What made it hard? For example, Rust seem to fit your bullet list.
You could just use C.
A large amount of C++ development is still focused on enterprise and UI apps, even though one could argue that it is not the best language for that purpose.
Someone needs to write a c++ 101 book, followed by 201 and 301 for beginner, intermediate, and advanced users.
But then, it's hard to find good programmers for any language, so C++ isn't really any worse off here, and better off than some in that at least there's a bunch of candidates to pick from.
I like to live in the embedded world and there I think Rust will shortly start to push out C and C++ at the wide-spread, commercial level. This is where my head is at, maybe it helps you formulate your opinion:
First, embedded C++ is not the same a full C++ (with features or library parts missing to accommodate the constrained environment). So I might never see some of the C++2x or even C++1x features. I really don't care about the C++2x standards since I might not see them in the next 10 years.
Second, memory and concurrency issues are real, even when you don't allow dynamic memory allocation after the system is initialized. We test, then test, and then run more tests, and turn on a lot of linters and analyzers but at the end of the day, they're bandaids. You can write terrible code in Rust, but you have to work harder to do it.
Third, if you really need an environment where memory is as fungible as play dough but want something portable (like inside a kernel), there will always be C. Setting up a C callable environment from assembly is well understood. In theory, calling into Rust shouldn't be any harder. But reading disassembled object files from C is generally reasonable assembler for the C I wrote. I haven't really tried doing that with Rust.
Fourth, it will take 5 years or so, but eventually we'll see commercially supported RTOS implementations for Rust that help companies to shield themselves from liability. For example, something like Threadx (AzureRTOS now). This will help push money in a virtuous cycle of better tooling -> more projects -> more money for tool venders -> better tooling.
Fifth, there will be Rust bindings to cover just about everything you do with C++ now (like game development) with high quality, idiot-proof, and portable semantics. You will find that junior developers or fresh-outs will have their skin crawl when asked to write "unsafe" code.
Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada.
But that's in the future. If I had to start a new project today (for a braking system on a train, for example), I would start with C, a validated RTOS, and commercial toolchain. If I had to light up my kid's halloween costume? Embedded Rust as a learning exercise. The rendering engine for a VR headset (with limited batter and compute), probably C++.
Rust is the only real competitor, but given the sheer amount of existing C and C++ code, the idea that they will become legacy languages any time soon is pretty out to lunch.
Rust is definitely difficult to learn, but I'll anecdotally say that Rust helped get me into the embedded world as someone with very little C or C++ experience. Unlike Ada, Rust has a modern toolchain and type system that feels very comfortable to developers coming from higher level languages, even if many of the concepts related to manual memory management remain quite difficult.
While some applications written in C++ are not performance sensitive, performance tends to be a major objective when choosing C++ for many applications.
Go is a good replacement for C and C++ for almost all purposes.
Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway.
The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.
Go also has the stop-the-world GC problem, GC is great but it does have a price tag.
I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.
What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a sublanguage. I know organizations where migrating to C++11 is still an ongoing process. It’s not great news if features become obsolete faster than many users can adopt them.
For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost to be read by other humans, but what was I trying to communicate by writing "volatile" on a parameter ?
The deprecation of composite operators on volatiles is an even better example. Those do something, but what they do might surprise programmers. Rewriting and then reading the rewritten example is an opportunity to discover that your code was broken anyway because now it's obvious. This obviousness is why deprecating the composites happened (and why it's sad that C++ 23 un-deprecates some of them).
"Most" maybe by count, but I'm not sure if it's "most" by usage frequency. There have been & will be lots of nonsensical deprecations that are much more common in existing code than "putting volatile on an object argument" (which I've honestly never even seen anyone do in my life)... like static (which was undeprecated, thankfully, but how were people supposed to know this ahead of time?), std::aligned_storage, std::bind1st, std::iterator. They're frustrating as heck, have questionable merits to begin with, and working around the deprecations in existing code provides practically zero business value.
extremely bold assumption. plenty of write-only or use-once code in the wild.
But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that.
Today, there's already static-code analysis tools that automatically migrate entire code-bases to use new language constructs. The technology is there. It's the people who lack imagination to make it happen.
Once it becomes commonplace, a large % of developers will care very little if some obscure feature of C is dropped. They'll just enjoy having a more streamlined language with all the legacy crap gone.
Rust provides best effort transformation for its Editions (which only touch syntax) in cargo fix --edition, but even that's only best effort. If a proc macro does something ludicrous (see Mara's whichever-compiles! macro for example) how can the transformation hope to keep up?
C++ versions are in much deeper, they not only change the language syntax, but also semantics of existing features. Sometimes the intended effect is null (but intentions may not match reality) and sometimes it is not.
C++ also substantially changes the standard library. Rust's standard library grows but doesn't get redefined in new Editions, so if you call a deprecated Rust function it's not going anywhere, whereas a deprecated C++ method might actually go away in a future version.
It's a shame that the best effort tools aren't provided with C++ compilers, but even if they were provided on a large codebase it's only the beginning for large projects.
Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was a brand new language, it should be easiest to do it there vs any system with legacy (although it was designed to interoperate with ObjC, so… maybe legacy remains).
If every time they're going to add things, remove things and break things then we're in practice talking different strands.
Imagine some preprocessor where you can mix them like
#flavor(ginger)
Instead of say c++11 and then proceed with whatever flavor as necessary.
I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.
They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility.
> If every time they're going to add things, remove things and break things then we're in practice talking different strands.
They are already different standard. What's there to miss?
> I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.
This take doesn't make sense. The C++ version being used in a project is a property of the project, not of the translation unit or individual files. A project is comprised of multiple declarations and corresponding definitions, which are spread around and reused and make sense as a whole. It would not make sense to, say, have a translation unit comprised of X C++11 definitions mixed with Y C++20 definitions.
Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?
One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers, into namespace std. A hello world in TenDRA looked like this:
#include <cstdio> // no <stdio.h> available
int main() {
std::printf("Hello, world!\n");
return 0;
}
I ended up writing a bunch of utilities for strings, including a unit testing library that spawned each test as a subprocess (to avoid exceptions) just so I could use GCC instead.
[0] There is no such version recorded on the GNU project website.
I’m nevertheless surprised that new noncontextual and previously-unreserved-identifier keywords were added at all. In earlier times, the approach would have been to use a reserved identifier like “_Yield” for the keyword, and to provide a standard opt-in header that would `#define yield _Yield`. Maybe they don’t want to add dependencies on the preprocessor anymore.
MSVC is the only major implementation that has std::format for now.
In any case, it's a really impressive effort from STL and the rest of their library team. STL has some incredible CPPCon talks, too.
Thus making the once famous clang having an honorable third place in ISO C++ compliancy.
Seeing this from a Google team makes it even more ironic.
That said, when I explore weird edge cases in how differently Clang and GCC parse source code, and how differently they optimise it, in my experience Clang is still the more logical one, whenever there is a disparity, whereas the way GCC parses code and what code it produces is sometimes completely baffling (and that's not just optimisation stuff - without any optimisations enabled I encountered miscompilations a lot more with GCC than Clang).
I also consider C++ a language for mostly old projects. I start new ones in other languages and don't consider repeated rewrites every two standards, because the "modern c++" crowd found a new way to initialise variables, to be a good investment of my time.
Back in the day (C++0x era), it was near bleeding edge. Clang had all the proposed 0x features ready to go before C++11 was released.
It took a while for GCC to get all the C++11 features after the release.
Same here, but I update my new code as I go if there is a better/safer way to do it that does not impact in any bad way my codebase.
Google at least is one of the largest contributors to the LLVM project -- it's just that their contributions don't tend to focus on Clang frontend work.
Not sure why Google would continue to contribute under those circumstances.
Google isn't even complaining about things, this is a very dry technical document about their experience, for an amount of work they certainly expected and were possibly even pleasantly surprised about.
These sorts of things are routine in massive code bases
After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation.
In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things like emscripten, llvmpipe, all sorts of static analysis tools that would be more challenging to build in the GCC universe, and much more.
Honestly, I thought GCC was slowing down development wise.
Is GCC worth trying again? Can you name a few "cool new things" I can do with GCC that I can't with clang? There's plenty of the opposite...
And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is.
Also, it's been a few years now since I did C/C++. So, maybe these are no longer the case.
Anyway, I've kinda pointed out what I like about clang over gcc, but I'd be curious what you prefer in gcc.
Given that llvm receive more human resources than gcc by far, I once expected it to outperform gcc generally (e.g support for polyhedral optimizations, BOLT, etc) Unfortunately weirdly it seems llvm performance is mostly stagnant. I personally suspect we are reaching increasingly diminishing returns with AOT and that the performance graal would be a hybrid that also does JIT at runtime (beyond PGO therefore) and more interpretable than BOLT
Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code.
Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run").
The language itself is stricter, with the safe subset being free of UB, so there's less stuff to break to begin with. You can't suddenly use a moved-from object.
There's even "cap lints" feature that disables `-Werror` equivalent for dependencies, so that new lints don't break your builds.
Well when rust makes changes every 6 weeks we all hold hands and update all of our code.
I like it, but it only aims at replacing ada, not c++.
I asked around and there is currently no good way to make modern native ui apps with rust.
It would be okay if the syntax of rust looked a bit more like C, but it doesn't, it can be a bit difficult to read.
- Experienced C and C++ devs have to unlearn certain patterns when they start Rust. C++ experience can be a huge help, but if you insist on using the patterns you're used to in Rust, you often have a terrible time and feel like the compiler can't handle useful programs.
- Particularly with C, what we usually mean when we say "learn" has gotten kind of out of date. If someone with a few years of programming experience says they "know" Python, we might assume they can make an HTTP request and parse some JSON with a couple minutes of googling the relevant API docs. But of course in C, those tasks are much more challenging, and we often allow that someone has "learned" C even if they can't do those things without great difficulty. Part of C's reputation for being (comparatively) easy to learn is that we don't expect programmers to be able to do the same variety of tasks with it.
- A lot depends on what standard of correctness and security we want to apply. For example, writing multithreaded code in Rust has an extra steep learning curve, but the resulting code is data-race-free once it compiles. Writing big multithreaded programs without data races takes many years of experience in C and C++, and it might be genuinely impossible for sufficiently large projects. So depending on what we understand "learning to write multithreaded programs" to mean, we could say that Rust is much harder but also that Rust is much easier.
Edit: There are also quite a few deprecation warnings, which are also not errors per se, but nevertheless you'd want to avoid using deprecated stuff of course.
Heck even Go folks are discovering their stable guarantee isn't as stable as they thought.
However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug.
So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies.
E.g. in languages with introspection it technically means you can't change anything.
I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11.
But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.
If you are looking for cycle-level performance, you likely need to use a more C-like subset of the language, but you can still use many conveniences like RAII and the smart pointers with 0 overhead (when construct/destruct are not in the critical path).
std::unique_ptr<Foo> doesn't have any overhead over Foo* in code where semantics is the same (i.e. you want to delete when going out of scope) on any sensible ABI - it has the same storage size, and all operations are trivially inlineable to the same exact thing you'd do with a raw pointer. About the only time I can think of where it can be slower is when the ABI insists that a struct cannot be passed or returned in a register.
Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters.
New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fast, fast, except =capture.
Measure often. Look for surprises.
The only way there would be would be if the compiler either can't optimize something as well because the lang changes requirements (this seems unlikely), or if they have bugs or inefficiencies because they haven't spent much time on the new standard.
If you're using new stuff from the new standard, they could be slower or faster or undecidable, really depends.
On voices against stripped down C++ (via code style): I find it working great in practice. Makes the codebase manageable, and keeps people away from using unnecessary complex language features (imagine Java code heavy with streams or reflection, or Python code that resolves most of dependencies at runtime, javascript full of eval(), etc.). Switching to a new language is half-baked plan.
I agree python dependencies are a worldwide shame and eval() is very niche (but again should not be universality banned assuming good developers, maybe though one could conditionally ban it aka it would trigger a lint during code review that would need explicit validation.
As for the topic at hands, google style bans are insane e.g. No Exceptions lol
I can see Reflection as problematic, but what's wrong with streams?
all these things are sometimes the best solution to a given problem
https://google.github.io/styleguide/cppguide.html#Exceptions
In the end, it makes code very difficult to reason about.
It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate.
This is quite nice in smaller systems, where you pretty much know every dependency and what calls will do.
But in larger, complex systems, where it is very hard to know or control every level of dependency, it is quite painful and fragile, because something 37 levels deep might suddenly throw new exceptions (or exceptions at all), violate 0 of the API guarantees that are being made[1], and start crashing your program in edge cases.
Among other things
[1] It's very easy for one library to say "we throw exceptions, something must catch them", and the dependent to say "we propagate all exceptions, we don't catch them". Even if something promises to catch them in the middle, it will very quickly get lost as it gets further away from the library actually throwing the exceptions.
The fact that you may be able to successfully assign blame or root cause to the problem doesn't help - being able to say something like "this library 36 levels deep in my dependency tree is not following best practices" is not a particularly helpful thing for development.
The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention.
Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.
That being said, it will make writing bindings a LOT easier, even though D already has direct binding to C functions.
This doesn't look very fun.
1. Google always seem to enjoy bucking the trend in terms of recommended ways to do things and end up using niche features that are likely to be deprecated 2. Chromium is a stupidly massive codebase so they have more things to fix just purely through scale
If you stick to the sane subset of the language that any competent modern C++ development shop would then you wouldn't encounter any of these problems except small/easy stuff like the new reserved keywords.
That being said, if you don't have a team that's already experienced in C++ then picking C++ is a bizarre choice.
Also my opinion seems unpopular on this topic, so I suspect some group of people that really want to get behind C++ don't like that kind of talk.
Whatever though. Rust and other newer languages are kind of giving the spaces C++ works well in a run for its money and in other ways just completely blowing it out of the water in my opinion.
It might be time to look at D again too.
The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21...
But this proposal from 2021 suggests only undeprecating bitwise compound operations:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...
The valid use cases for it are ridiculously few.
I was wondering about that slide that says the meaning is unclear, I don't see what's unclear about it. What particular assembly instructions it translates into is irrelevant. It's not like ++ is guaranteed atomic or anything.
The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. The semantics around moving and copying and the many ways you can initialize a variable [1] and how you can mess that up so it's actually a copy instead of a move is just mind-bending.
Can we also talk about how in 2022 we're still talking about and getting wrong const-correctness? I guess we're going ever further now because this presentation touches on constexpr correctness (as in const vs constexpr).
Another thought: problems like comparisons between base and derived problems shouldn't even be problems (IMHO) because you've already messed up by wanting that behaviour.
The change about not doing arithmetic on enum values is a good one but pretty late.
TIL this is a valid way to cast:
size_t{expanded_size}
I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates.
Thus around 1400 pages of a 1900page doc are dedicated to specify libraries that throughout the years have been adopted by the standard. We're talking about stuff that was released with Boost and since then was deemed appropriate to make it standard.
Focusing on the 460 pages that specify the core language, most of this content has not been changed since C++98. The C++14 doc covered the core language with around 420 pages. Thus it makes zero sense to claim than suddenly C++ became horrifying because of the extra 20 sheets of paper you need to print out.
1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and
2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually use C++ without any of the standard library?
Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream.
Visual C++ is already there in C++20 and increasingly improving C++23 support as well.
I work on Ruby compilers and people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.
Is there anything I can read to get up to date quickly?
Maybe.
> JS
Hell no. "Frameworks" like React or Vue exist solely for the purpose of retaining developer sanity in the face of unregulated JS code.
https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
And I noticed the ban of shared_ptr and <chrono>. I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queues. But are raw-pointers just used instead of shared_ptr when shared ownership is needed?
Also banning use of <chrono> ?
Can someone try to explain the possible reasons?
Regarding smart pointers, not sure if you also found this: https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
If a tech giant wants this to happen - e.g. because memory un-safety is mostly the root of all evil - they can use people from the current team and throw a few millions on hiring new talent.
Also it’s just rewriting the logic. One could theoretically write unit tests for every function to make sure the inputs/outputs match.
He covers learning programming and books like the one you mentioned.
You can either do the correct thing, or the succinct thing. There's hardly ever a satisfying compromise between the two either. Obviously, we want to do the correct thing most of the time, so that's why C++ ends up being full of ceremonious implementations in practice.
And alas, they're usually equally ceremonious to use, because abstractions in C++ are so incredibly leaky because of its poor type system.
I'm not sure why that is, but my gut tells me it's all this backwards [pseudo]compatibility.
We are really keen on preserving backwards compatibility, but break existing code anyway. We will not define a stable ABI, but also won't fix stdlib if it breaks ABI.
Also all code definitely has UB in it waiting for a compiler change to expose it as wrong and deserving of no longer working.
Ceremonious captures the state of the art accurately.
Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
Half of the "features" shown in the presentation are exceedingly niche. It's just that a 20 million LOC (or however many Chrome has right now) code base is almost guaranteed to exercise every niche feature somewhere.
Having helped with C++ standard transitions of a code base half an order of magnitude smaller, the amount of issues requiring code changes was minuscule so far. You tend to have much more boring problems, like:
- "We can't use newer C++ because C++/CLI doesn't support it"
- "We can't use newer C++ in these headers because they end up included in CUDA code, and that compiler only supports C++14"
- "We have to wait for a new version of <tool> before we can lint/sanitize/profile/format our code"
- "This third-party code has the compiler up in arms now because it does questionable things"
So, backwards compatibility is there (if we ignore newly introduced keywords).
As some comedian used to quip, Pregnant Guppy would be a good band name.
const int MAX_SIZE = 1024;
const int HEADER_SIZE = 128;
set_content_size(HEADER_SIZE - MAX_SIZE); set_content_size(MAX_SIZE-HEADER_SIZE);
In C++, const int x = 3 is already a constant. As of C++98 already, you can use x as a case label in a switch statement.
It cannot be any more constant.
Not cool any more?
His response was, "I already have a new language to learn: c++".
* std::filesystem::path broke some APIs with the introduction of u8string.
* some deprecated interfaces of std::allocator got removed.
It was easy enough to resolve and we are in the process of switching to C++20.
Best line in the deck:
"Only write complicated code when you truly need performance. Comment if you do...."
I guess once again you do actually end up paying for what you don't use.
> Solution: Don’t care?
:(
Would have been nice if they at least analyzed where the increase was coming from. Maybe operator<=>?
Also, I don't understand why there are so many negative views on C++. C++ is a beast, but somehow you can control it, and C++ is too popular and still in use to be replaced by anything else in the near future.
But here I found some benchmarks (did not inspect though): https://www.phoronix.com/review/11900k-gcc11-clang12/2