C++ has become extremely big, maybe an iteration would be beneficial?
Ask HN: Should the C++ committee freeze STD and make STD2?
1–9 of 9 posts
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#2I like the Rust way of telling the compiler driver with a command line switch which compiler version to run, then backward compatibility as a problem disappears.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#3[deleted]
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#4If they decide to accept the Safe C++ proposal, it will require it. We’ll see.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#5I have no skin in the game and rarely code in C++. My answer is: no.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#6C++ has become such an unwieldy monster that even though I've been primarily a C++ programmer from the very start of the language and am an expert in it, I've come to dread using it or maintaining software written in it.
Anything that stops or slows down the madness is welcome.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#7As long as old code continues to compile and run correctly on new compiler/language versions, I don't care what the committee does. From my point of view they should first and formost decelerate, so that there is at least enough time for compiler writers to keep up and collect enough experience between the standards. Cross-compiler compatibility has become an adventure since C++11. I only use a very conservative subset of the language to maintain compatibility.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#8How would that help? The old functionality would still be around.
What would help is deprecating and, over time, removing features that, if needed, are better implemented on top of newer, better APIs. Providing source code for such an implementation would make it easy for old code to be changed to compile with the new version; all that would be needed would be changing #include by #include "foo" and changing references to the std namespace to that of the new library (there may be thorny edge cases here, but I can’t think of one)
For example, iostreams can be moved outside of the standard if an implementation of its API on top of std::format were provided.
I think they wouldn’t have to support such a library forever. A decade or two should IMO be enough. If code needs it after that, they can take on the burden of maintaining it.
Re: Ask HN: Should the C++ committee freeze STD and make STD2?
#9As long as old code continues to compile and run correctly on new compiler/language versions, I don't care what the committee does. From my point of view they should first and formost decelerate, so that there is at least enough time for compiler writers to keep up and collect enough experience between the standards. Cross-compiler compatibility has become an adventure since C++11. I only use a very conservative subs…
> I only use a very conservative subset of the language to maintain compatibility.
This is what I do in my own projects, but I don't have that option at work.