Hacker News Reader

For C++17, the only best thing for me was that you can destructure tuples and pairs with a simple syntax (when otherwise you needed to use std::tie)

    auto [a, b] = functionThatReturnsATuple();

For C++20, the one single thing I'm excited about is designated initializers (which was already in C99! It's kinda mad why this came so late). Basically you can initialize structs with parameter names with just a single line of code:

    struct Person {
        std::string name;
        int age;
    };
    Person person = {.name = "Bob", .age = 29};

Anything else from C++17 and onwards I really don't find a usage for right now. Compile-time programming using constexpr and consteval is great, until you realize that compile-time programming works under the hood by evaluating the AST directly (which is the slowest possible way for an interpreter), and would make your build times skyrocket to the moon. Concepts are kinda nice because of better error messages, but doesn't really matter for me if heavily templated libraries like STL and Eigen aren't fully ported for this feature. Ranges are just unnecessary for me, I learned the hard way that for loops are much better in terms of clarity and performance. And for modules: again, it only matters if the STL, tooling, and major libraries are ready for it, and I'm skeptical it will be achieved at any time.

For C++20, I agree with you on Concepts. They're nice to have, but its probably going to be quite rare that I will use them. I am, however, interested in coroutines and modules too (the other two of the three main things 20 adds). I also agree on the initializers, that's something I wish C++ had added long ago, since C has had it for so long.

Funny thing is, I didn't even think of ranges while writing my comment above. I like the idea of them and they do allow some nice code, but its not something I've been wishing I had.

For C++17, there's a bunch of small things that I like: standard attributes like [[nodiscard]], nested namespace definitions are a nice convenience, constexpr if statements and some of the library additions are nice (string_view, optional, etc). Destructuring auto, as you said. Nothing as exciting as what C++11 or 20 adds, but still nice to haves.

If that is your favorite thing from C++20, I have very good news for you: You hain't seen nothin' yet.

Saying concepts are just for better error messages is like saying types are just for error checking. You can rely on them only for that. Or you can put them to work.

Most of what makes C++ powerful is from putting types to work. Concepts are just as powerful. You haven't seen yet what they can do.

Agreed. They are the compile-time interfaces to templates' compile-time classes (so to speak, though obviously templates aren't limited to classes). I've been wanting them for so long; naturally error messages are better, but documentation will be better integrated/generated too. Just being able to understand what's expected of a templated type in a compile-time verified way is invaluable. I've taken to writing the concepts I'm using in comments (in the concept syntax) and can't wait to start uncommenting them.

Really, you can now overload based on concept matching, and so tailor implementations according to the family of types passed, analogously to overloading regular functions based on actual types, and overloading templates based on partial matches.

Concepts are a fundamentally powerful tool. Haskell people will recognize them as akin to what they call type classes.

Thus, in P2187 http://wg21.link/p2187 we have conditional swap that, for any small- and simple-enough type, is swapped using CMOV instructions instead of a probably badly-predicted branch. This mechanism works in released Gcc-10 today. (Note that what goes into the Standard Library will probably differ, in details, substantially from P2187R5.)

> you can now overload based on concept matching

Can you use this to compile-time detect if a class has a particular member function?

I've used code like this before, and the implementation has always been a bit of a mess, so I wonder if it can be simplified with concepts:

    template <class T> void foo (T& t) {
        if constexpr (hasMemberBar<T>()) {
            t.bar();
        }
    }

Currently, I use this to implement hasMemberBar and I wonder if there's a better way now: https://gist.github.com/danielytics/8944b51ca51280fba30baab6... Especially something that works without using the preprocessor, while still not needing a new implementation for each member I wish to check for.

I want to use concepts, but it's not integrated with the STL yet (which is a baffling decision - aren't you supposed to dogfood new features into the standard library if you want to encourage its usage and test its strengths and weaknesses?...) My code is not that heavily templated (and wouldn't benefit that much in doing so), so the only reason concepts would be good for me right now are having better error messages in other heavily templated libraries like STL and Eigen.

> > Long ago "modern" C++ crossed into a territory that I will never understand or use.

> Do you know where the line is? C++11? Later versions?

It's funny to read this, because I purposely avoided C++ for the better part of twenty years after dabbling with it in college--not worth it to deal with so much complexity. I've started using it in the last couple of years for work, and the modern part is what makes it bearable.

C++ is a big beast, so there is a cost to each new standard simply by virtue of adding features. However, the types of things I want to use in C++14 are pretty simple and worthwhile; e.g., better constexpr functions, and the _t aliases (like std::enable_if_t<>, rather than typename std::enable_if<>::type). Similarly, C++17 has a few new templates, like std::optional and yes, std::variant, along with ergonomic improvements like the _v aliases (like std::is_floating_point_v<>, rather than std::is_floating_point<>::value).

Now that the glacial pace of standardization has been replaced with a three-year cycle, I almost want something like LTS releases. I use C++11, and a bit of C++14, but when is it safe to use C++17 or C++20?

C++14 is really just a small patch of improvements to 11, so I think if you're going to adopt 11, you may as well adopt 14 and get a better experience.

And that is where I intended to stop, but then I started reading and watching content on C++17 and realised the things I thought were complex and scary were not so bad. I mean, there's much code I just don't understand, but from how it affects me personally, its not so bad and adds a bunch of improvements.

C++20 is a different beast altogether and I told myself its too complicated so I'll never bother beyond C++17. And then I watched some cppcon videos and realised that concepts, ranges, modules and coroutines are pretty cool. I still don't understand anything but the basics of concepts and ranges have some cool properties, but otherwise I dunno if I'll use them. But coroutines open a world of interesting possibility and modules have a lot of potential too, so I've started playing around with C++20 and will slowly learn to use it (although I did already notice some stuff that's not yet implemented in the clang version my package manager gave me... so not quite ready yet).

I've been using C++ about as long as OP, and I found much of C++11 to be practical and useful so adopted the useful bits into my tool chest. Since then, the additions seem (to me) to be more academic and interesting to computer scientists, so I haven't really found the need to keep up. I think C++11 hit the sweet spot. Threading, Smart pointers, std::unordered_xxx hash tables, strongly typed enums, lambda functions, are great and useful. Tuples, initializer lists, range-based for loops, type inference are convenient, I don't see how they hurt. R-value references and constexpr are neat academically, but I've so far failed to see the practical killer app for them, or how they could improve my existing code. The rest of C++11, I either haven't looked into or just haven't been convinced make my code better than without.

> R-value references ... are neat academically, but I've so far failed to see the practical killer app for them,

The killer app is unique_ptr. Without move semantics, unique_ptr wouldn't be nearly as nice to use. There's a good reason that it has a move constructor but not a copy constructor.

That and of course improved performance by avoiding copies where they aren't needed. This is easily benchmarkable in practice.

Sometime around smart pointers, or "managed" pointers. If I can't figure out how to use something in a few minutes, it's probably going to cost more in overhead than it benefits.