3 ms·

Do you interact with any significant C++ code base? Because I'm having a hard time seeing what your practical recommendations would be past the idealism. Yes,

Do you interact with any significant C++ code base? Because I'm having a hard time seeing what your practical recommendations would be past the idealism. Yes, you can have major breaking changes every few years. But do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Should they all be rewritten for each version?` Don't get me wrong, I'd love if we could deprecate more old stuff. The problem is that it doesn't just disappear from existing code (of which there is a _lot_) by marking it as such. If there are straightforward replacements (e.g. auto_ptr -> unique_ptr) that's one thing, but unless you want each new C++ standard to be unusable with existing code, you can't just do that.

notacoward 8y ago
> Do you interact with any significant C++ code base? Yes. It's the codebase for one of the largest data storage systems in the world. If it stopped working, literally billions of people could be affected. Is that good enough to get past the ad hominem? > past the idealism. Is the idealist the one who questions the wisdom of changing a codebase that already works, or the one who demands it? It's all too easy to accuse others of being too idealistic, or to make up strawmen (see next point), but I don't think those are very constructive ways to approach a discussion. > do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Of course not. But the transition from old idioms to new ones can be managed. The first thing that has to happen is that the people adding new features to each standard must be explicit about which old features are being deprecated when. Sure, you can specify --std=c++25 to get the new hotness, but then that might preclude use of old feature xyz from C++11 in the same compilation unit. You have to choose, and you should choose, according to pragmatic needs instead of mere neophilia. > unless you want each new C++ standard to be unusable with existing code Controlled deprecation doesn't necessarily mean 100% incompatibility between versions. N-1 is a very common model, which can be extended across any K prior releases. There are tons of examples, not only from languages but from APIs, file formats, operating systems, and even other kinds of engineering besides computers. People should absolutely be given time to adjust, but the time should be finite. "Simultaneously support everything that every existed" is the one model that's least likely to work in the long term.

notacoward 8y ago

> Do you interact with any significant C++ code base? Yes. It's the codebase for one of the largest data storage systems in the world. If it stopped working, literally billions of people could be affected. Is that good enough to get past the ad hominem? > past the idealism. Is the idealist the one who questions the wisdom of changing a codebase that already works, or the one who demands it? It's all too easy to accuse others of being too idealistic, or to make up strawmen (see next point), but I don't think those are very constructive ways to approach a discussion. > do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Of course not. But the transition from old idioms to new ones can be managed. The first thing that has to happen is that the people adding new features to each standard must be explicit about which old features are being deprecated when. Sure, you can specify --std=c++25 to get the new hotness, but then that might preclude use of old feature xyz from C++11 in the same compilation unit. You have to choose, and you should choose, according to pragmatic needs instead of mere neophilia. > unless you want each new C++ standard to be unusable with existing code Controlled deprecation doesn't necessarily mean 100% incompatibility between versions. N-1 is a very common model, which can be extended across any K prior releases. There are tons of examples, not only from languages but from APIs, file formats, operating systems, and even other kinds of engineering besides computers. People should absolutely be given time to adjust, but the time should be finite. "Simultaneously support everything that every existed" is the one model that's least likely to work in the long term.