4 ms·

> 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? I ask because I qu

> 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? I ask because I quite like a lot of the changes that C++11 brought to the language, I feel they make my code much simpler to understand and maintain, but I got very confused by post-11 C++ for a long time to the point where I said I'd never bother with C++17 or later (14 turned out not to be too scary once I actually sat down with it) because 17 and 20 added so much stuff that just looked beyond me. But I've since changed my mind and have started to experiment with C++20, after I sat down and read a few articles and watched a few cppcon videos on the changes. I don't know all that these versions have to offer, but I do understand the main changes enough to get by and most of them do make the language better, in my opinion. Overall, the language is a mess, simply because they keep adding to it and very little stuff gets deprecated, removed, changed or cleaned. That leaves a large and messy language, especially compared to more recent deliberately-designed languages, but it turned out I could understand "most" of the things, once I had someone explain them to me. A few times ;) Having said that, it probably isn't worth your time to "modernise" the C++ in your money-making codebase at this stage, if you're comfortable with it how it is. You likely wouldn't see a return in the effort it would take.

lasagnaphil 6y ago
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.
- dkersten 6y ago
  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.
- ncmncm 6y ago
  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.
  - afranchuk 6y ago
    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.
    - ncmncm 6y ago
      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 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.)
ryandrake 6y ago
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.
- FartyMcFarter 6y ago
  > 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.
  - FartyMcFarter 6y ago
    That and of course improved performance by avoiding copies where they aren't needed. This is easily benchmarkable in practice.
SloopJon 6y ago
> > 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?
- dkersten 6y ago
  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).
GnarfGnarf 6y ago
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.

lasagnaphil 6y ago

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.

dkersten 6y ago
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.
ncmncm 6y ago
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.
- afranchuk 6y ago
  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.
  - ncmncm 6y ago
    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 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.)

ryandrake 6y ago

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.

FartyMcFarter 6y ago
> 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.
- FartyMcFarter 6y ago
  That and of course improved performance by avoiding copies where they aren't needed. This is easily benchmarkable in practice.

SloopJon 6y ago

> > 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?

dkersten 6y ago
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).

GnarfGnarf 6y ago

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.