4 ms·

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") disagre

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.
MadWombat 7y ago
"That compatibility has been absolutely crucial for the language's continued success" I am not sure I buy that argument. The problems with Python 2->3 were mostly about Guido and his management style rather than actual language. People were not sure how long Python 2 would be maintained and whether or not they would need to support both and how that would work and all sorts of things like that. And Python 3 was not very complete on release, with a lot of things changing rapidly and backward compat getting shoehorned back into P2. With C++ committee approach this is a lot less likely to be a problem. I think the reason things never get dropped is because C++ is not well designed. It is basically C with OOP and generics bolted onto it. So low level C stuff like direct memory access is built-in. And since OOP is kind of an afterthought, there is a split between parts of language that do fall under the OOP system and parts that don't. So you can introduce something like std::string using the OOP system and make it super safe, but you cannot replace C strings with it simply because C strings (and direct memory pointers in general) are a core part of the language that is not connected to OOP in any way. Same goes for smart pointers and iterators and functor structs and what not. Most of the cool things in C++11 and C++17 are firmly planted in the OOP world and cannot affect anything that is the "original C" part.

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.

MadWombat 7y ago

"That compatibility has been absolutely crucial for the language's continued success" I am not sure I buy that argument. The problems with Python 2->3 were mostly about Guido and his management style rather than actual language. People were not sure how long Python 2 would be maintained and whether or not they would need to support both and how that would work and all sorts of things like that. And Python 3 was not very complete on release, with a lot of things changing rapidly and backward compat getting shoehorned back into P2. With C++ committee approach this is a lot less likely to be a problem. I think the reason things never get dropped is because C++ is not well designed. It is basically C with OOP and generics bolted onto it. So low level C stuff like direct memory access is built-in. And since OOP is kind of an afterthought, there is a split between parts of language that do fall under the OOP system and parts that don't. So you can introduce something like std::string using the OOP system and make it super safe, but you cannot replace C strings with it simply because C strings (and direct memory pointers in general) are a core part of the language that is not connected to OOP in any way. Same goes for smart pointers and iterators and functor structs and what not. Most of the cool things in C++11 and C++17 are firmly planted in the OOP world and cannot affect anything that is the "original C" part.