It's very much implementation defined yes. I'm currently using this for something that runs for about 10 seconds, and even music playback and mouse cursor movement gets affected.
You need to be aware that these invocations are going to blast your cores full throttle as you obviously don't have fine grained control. But as long as your data is easily parallelized on a vector with computations that don't depend on each other, it's a game changer. I use it all the time to multithread things with literally a single line of code.
Yes... But you don't need to memorize all this, and it leaves out a simple rule: vectors (or arrays) outperform everything else if the dataset is small. Small is usually in the order of 100-300, but can vary wildly.
Also note that all <algorithm>s have built-in fully automatic parallelism via <execution>, a massively underused feature. In typical CPP fashion though, their newer views:: counterparts lack those overloads for the moment.
Reflections alone would be one of the most impactful additions. And in contrast to most others: very difficult to do otherwise. I'm a bit surprised by the sudden push after long phase where it seemed like they would never come.
Contacts: yes please. Variadic indexing is one of those things everyone writes their own helper for. But this standard facility is very welcome indeed.
Some additions seem a bit of of scope for the standard of a language that famously refuses to fix mistakes. So in weary about std::hive, networking, physical units.
And an underrated cherry is at the end: cleaning up those "ill formed, no diagnostic required" clauses in the standard. For those who don't know: there are things forbidden in the standard which the compiler is allowed to not tell you (because it's difficult for the compiler to prove it). In particular this is omnipresent in the constexpr world. Leading to silly redundant code that manually assets things to explicitly trigger the compiler to check for errors.
And that's a criticism I can take to a degree on behalf of the language. These relics are still in because mistakes are happening in the governing body. However in practice, they don't matter much. Every CPP dev has a little helper running in the background which immediately flags these mistakes and can auto correct them. It's not an issue, just an annoyance.
I've never read a programming book that was worth it. In the time and the energy it takes to read, I could have always learned more by reading a tldr and trying things myself
For some reason, the comparison is always current rust Vs 20 year old c++. Mentioning that "modern" (12 year old) c++ does not have these problems gets downvoted.
Completely unrelated: there are at least two dedicated anti c++ communities.
This doesn't fly with a one man team and not with a 1000. It's just badly done, there's no sugarcoating. Those meshes should never end up in the game files.
It's a bit hard to get an overview. But I did spot several uses of owning raw pointers and switching from those to managed ones. I'd say that's exactly the point I was trying to make.