3 ms·
Honestly, there's a "lot" of extra stuff but the standards committee has a general standard that things that can be done in a library don't need to be supported
by mauvia 3y ago
Honestly, there's a "lot" of extra stuff but the standards committee has a general standard that things that can be done in a library don't need to be supported on the language level, meaning 90% of the new stuff is going to be invisible to you except in making the language more ergonomic to use.
An easy example is ranged-for. It depends on so much complexity internally that the end-user basically will never see. All they'll see is that as long as std::begin and std::end are defined for a container you can just `for (auto item : container)` it. Stuff like overload resolution is essential to it but you don't need to know overload resolution rules to use ranged-for.
Or the way initializer lists make initialization so much simpler. The way you can leave constructor writing to the compiler for so many different types of constructors.
How the compiler handles elision so well because of how the constructors are designed. You don't need to write a single rvalue reference move constructor for simple types. They're generated for you.
The current ongoing push to make large parts of the standard library constexpr so you can have seriously complex things going on directly at compile time to result in a minimal output that can just put in equivalent constants to constexpr function calls.
Like, the reality is, it is pretty much a core principle of the language that you can write C++2003 if you really want to, and everything on top of it just makes writing things easier. But if you want to piecewise substitute your code with the latest stuff it more often than not becomes terser and more straightforward because of the evolution of the std library.