I feel like he went through all this effort just to make the joke "A more perfect union."
But seriously, a great write up. std::any looks like it could be dangerous in the hands of the inexperienced, especially in a sea of other changes that makes working with types easier and safer.
Every time I see one of these new revisions, I can't help but think that the type system has become the roadrunner and the STL has become wile e coyote, complete with dynamite and cartoon physics.
Seriously though, does anyone actually use any of the post-C++-11 stuff? I can count on one hand the times I've seen nonironic use of a C++-11 extension in a real project, and I've never seen use of -14 or -17 extensions.
I've used boost::optional for a long time. It is long overdue in the standard. NULL should almost never be a valid value. It is also quite useful to enable safe lazy initialization without heap allocation.
std::variant is just a discriminated union. That's useful for lots of things.
C++11 is old school at this point. Other than for legacy reasons, no one should be using the older stuff.
C++17 is not released yet and the current major C++17 implementations aren't ready for production use.
C++14 doesn't have many new features. C++14 contains many fixes on minor details which was implemented even in C++11 implementation because the Standard wording of C++11 is either ambiguous, impossible to implement, considered too harmful on that fixed part.
Yes, good C++ programmers use them. By 'good' I mean good enough at their profession to have bothered to pay attention to developments outside of their immediate experience over the last 5-10 years. Which is a pretty low bar, really.
As someone that does Java and .NET consulting, with an ocasional use of C++ on the projects, I would say outside the SV darlings (Google, FB, Microsoft, Apple, ...), sadly very few people do.
While I do try to keep up with the standard, the majority of the code I bump into, on those projects, is still the typical pre-C++98 style and most devs aren't that keen in moving forward.
Specially in projects that are mostly driven by changing consulting company every few budget rounds.
Most of it seems pretty real-world to me. But if IIUC that std::filesystem means I don't have to write separate code for windows and linux, then it's hard not to imagine EVERYONE using that.
Most of it seems pretty real-world to me. But if IIUC that std::filesystem means I don't have to write separate code for windows and linux, then it's hard not to imagine EVERYONE using that.
I'm with you on most of it... the one thing that seems really appealing is concepts and constraints. If for no other reason than to restore sanity to template error messages. Check out Bjarne's writeup about it for another nice perspective: https://isocpp.org/blog/2016/02/a-bit-of-background-for-conc...
The "structured bindings" feature seems potentially dangerous. I guess it helps unpacking tuples and getting references to tuple members. But it seems to have opened up a whole new set of side effects.
This is true, though generally anytime one uses `auto` it should be `const auto&` to avoid swallowing the quantifiers and potentially costly copies anyways.
20 comments
[ 181 ms ] story [ 752 ms ] threadBut seriously, a great write up. std::any looks like it could be dangerous in the hands of the inexperienced, especially in a sea of other changes that makes working with types easier and safer.
Seriously though, does anyone actually use any of the post-C++-11 stuff? I can count on one hand the times I've seen nonironic use of a C++-11 extension in a real project, and I've never seen use of -14 or -17 extensions.
std::variant is just a discriminated union. That's useful for lots of things.
C++11 is old school at this point. Other than for legacy reasons, no one should be using the older stuff.
Many major C++ projects are using C++11, e.g. LLVM/Clang, Chromium, etc.
C++14 doesn't have many new features. C++14 contains many fixes on minor details which was implemented even in C++11 implementation because the Standard wording of C++11 is either ambiguous, impossible to implement, considered too harmful on that fixed part.
While I do try to keep up with the standard, the majority of the code I bump into, on those projects, is still the typical pre-C++98 style and most devs aren't that keen in moving forward.
Specially in projects that are mostly driven by changing consulting company every few budget rounds.