4 ms·

Yes, it's very complex and hard to stay on top of current best practices. However, every one of the major features listed in this post replace an existing lang

Yes, it's very complex and hard to stay on top of current best practices. However, every one of the major features listed in this post replace an existing language feature with something that is easier/safer/less verbose. For new code you shouldn't have to use the old features, and you can just rely on the new ones. Existing code is trickier, which is already a problem for large C++ codebases. You'll find dramatically different styles depending on when the code was written. All in all, though, the recent changes have made C++ much more pleasant to program in. They're mostly less complex for an application developer than the things they are replacing, and the really complex bits (concepts, etc.) are only needed for writing complicated template libraries.

eikenberry 7y ago
Does anyone know of a mind-map or info-graphic that sort of lays out the new features and which older features they replace. Something to help someone who hasn't looked at C++ in years get a feel for how to map things?
MadWombat 7y ago
"every one of the major features listed in this post replace an existing language feature" That is the part that annoys the hell out of me in regards to C++. Nothing ever gets replaced, things just get added on top of everything. And to add to that there is generally very little indication which is the "new, safe and cool way" and which is "old, shoot yourself in the foot" way of doing things. Like std::string is cool and generally you want to use it everywhere... except you can use []char everywhere and be completely unaware that you are doing anything wrong (well, until you segfault on memory access). Or unique_ptr and shared_ptr and auto_ptr. Cool things, but you can use a regular pointer in their place and again, never realize something is wrong (again, until you segfault). And every C++ book I ever saw happily discusses raw pointers and memory allocation and []char strings without ever giving you any warning that under most normal circumstances you should not use any of this.
- alexhutcheson 7y ago
  Yeah, I agree that part is frustrating - it's very difficult to stay on top of current best practices, especially when even experts (and many "experts") disagree on best practices. The "Nothing ever gets replaced" problem is a direct consequence of the committee's focus on backwards compatibility. That compatibility has been absolutely crucial for the language's continued success. Backwards-incompatible changes would result in even more divergence between the C++ dialect supported by various compilers and compiler versions, and would probably result in an even worse version of the problems that occurred in the Python 2->3 transition. In my experience, the the ABSL "Tip of the Week" posts[1] are a great source for "best practice" info, but they aren't exhaustive, and some are specific to the ABSL libraries, rather than general C++. [1] https://abseil.io/tips/ https://abseil.io/tips/
  - gigatexal 7y ago
    The act of not replacing things though doesn’t go further enough imo — if b is truly better in every way and also functionally equivalent to a then in the version that b came out in it should only have b and deprecate with compiler warnings or fail to compile with a so as to move the language forward
    - alexhutcheson 7y ago
      That's an option, but it's a risky one, because you could end up with a balkanized language with many different C++ dialects depending on compiler version and platform. The amount of existing code in the world is huge, and not every organization has the resources, knowledge, or desire to move to the new hotness every time an improvement to the language was made. The Python 2->3 transition is an example of what can happen when you make backwards-incompatible changes to existing language features. We're more than a decade in, and there are still huge volumes of code at major organizations that haven't made the switch. This happened despite the fact that the people proposing the change also controlled the change and release process for the major implementation of Python, a case which is not true for C++. It's also difficult because many proposed backwards-incompatible changes or deprecations would break ABI compatibility, which would prevent a library and binary (or 2 libraries) that were compiled using different compiler versions from inter-operating. This breaks a core workflow for many C++ users. To get a better understanding of the committee's priorities, I would recommend looking at "The C++ Programmer's Bill of Rights": https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-standards-committee-be-doing https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-stan... It's not a formal commitment from the committee, but it will give you a sense of what their priorities are.
pizza234 7y ago
> every one of the major features listed in this post replace an existing language feature with something that is easier/safer/less verbose I'd argue that the each new feature adds on top of an existing one. 30+ years of existing knowledge won't vanish, and will cause decades of unintended Frankenstein codebases (followed by decades of even more Frankenstein ones).
gigatexal 7y ago
That makes sense. So you could take a C++11 codebase and incrementally change things to C++20 (using a complaint compiler of course). I wonder if there will be a huge market for people who truly understand all versions of the language who will be consultants hired to upgrade large codebases
- alexhutcheson 7y ago
  Backwards-compatibility means you shouldn't actually have to upgrade large codebases. If the codebase isn't changing much, then you can leave it as is, and it will continue to work with new compilers. If you are making changes, then you can add C++11/C++20isms to the parts of the codebase that you're working on, and leave the rest alone. No need to bring in a consultant to change the whole thing.

eikenberry 7y ago

Does anyone know of a mind-map or info-graphic that sort of lays out the new features and which older features they replace. Something to help someone who hasn't looked at C++ in years get a feel for how to map things?

MadWombat 7y ago

"every one of the major features listed in this post replace an existing language feature" That is the part that annoys the hell out of me in regards to C++. Nothing ever gets replaced, things just get added on top of everything. And to add to that there is generally very little indication which is the "new, safe and cool way" and which is "old, shoot yourself in the foot" way of doing things. Like std::string is cool and generally you want to use it everywhere... except you can use []char everywhere and be completely unaware that you are doing anything wrong (well, until you segfault on memory access). Or unique_ptr and shared_ptr and auto_ptr. Cool things, but you can use a regular pointer in their place and again, never realize something is wrong (again, until you segfault). And every C++ book I ever saw happily discusses raw pointers and memory allocation and []char strings without ever giving you any warning that under most normal circumstances you should not use any of this.

alexhutcheson 7y ago
Yeah, I agree that part is frustrating - it's very difficult to stay on top of current best practices, especially when even experts (and many "experts") disagree on best practices. The "Nothing ever gets replaced" problem is a direct consequence of the committee's focus on backwards compatibility. That compatibility has been absolutely crucial for the language's continued success. Backwards-incompatible changes would result in even more divergence between the C++ dialect supported by various compilers and compiler versions, and would probably result in an even worse version of the problems that occurred in the Python 2->3 transition. In my experience, the the ABSL "Tip of the Week" posts[1] are a great source for "best practice" info, but they aren't exhaustive, and some are specific to the ABSL libraries, rather than general C++. [1] https://abseil.io/tips/ https://abseil.io/tips/
- gigatexal 7y ago
  The act of not replacing things though doesn’t go further enough imo — if b is truly better in every way and also functionally equivalent to a then in the version that b came out in it should only have b and deprecate with compiler warnings or fail to compile with a so as to move the language forward
  - alexhutcheson 7y ago
    That's an option, but it's a risky one, because you could end up with a balkanized language with many different C++ dialects depending on compiler version and platform. The amount of existing code in the world is huge, and not every organization has the resources, knowledge, or desire to move to the new hotness every time an improvement to the language was made. The Python 2->3 transition is an example of what can happen when you make backwards-incompatible changes to existing language features. We're more than a decade in, and there are still huge volumes of code at major organizations that haven't made the switch. This happened despite the fact that the people proposing the change also controlled the change and release process for the major implementation of Python, a case which is not true for C++. It's also difficult because many proposed backwards-incompatible changes or deprecations would break ABI compatibility, which would prevent a library and binary (or 2 libraries) that were compiled using different compiler versions from inter-operating. This breaks a core workflow for many C++ users. To get a better understanding of the committee's priorities, I would recommend looking at "The C++ Programmer's Bill of Rights": https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-standards-committee-be-doing https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-stan... It's not a formal commitment from the committee, but it will give you a sense of what their priorities are.

pizza234 7y ago

> every one of the major features listed in this post replace an existing language feature with something that is easier/safer/less verbose I'd argue that the each new feature adds on top of an existing one. 30+ years of existing knowledge won't vanish, and will cause decades of unintended Frankenstein codebases (followed by decades of even more Frankenstein ones).

gigatexal 7y ago

That makes sense. So you could take a C++11 codebase and incrementally change things to C++20 (using a complaint compiler of course). I wonder if there will be a huge market for people who truly understand all versions of the language who will be consultants hired to upgrade large codebases

alexhutcheson 7y ago
Backwards-compatibility means you shouldn't actually have to upgrade large codebases. If the codebase isn't changing much, then you can leave it as is, and it will continue to work with new compilers. If you are making changes, then you can add C++11/C++20isms to the parts of the codebase that you're working on, and leave the rest alone. No need to bring in a consultant to change the whole thing.