2 ms·
You don't usually improve the standard for legacy code. You want backward compatibility, sure, but the expectation that a new standard automatically makes old c
by cheez 12y ago
You don't usually improve the standard for legacy code. You want backward compatibility, sure, but the expectation that a new standard automatically makes old code not suck is just setting you up to be disappointed.
What C++ has allowed us to do is slowly (sometimes wholesale), add the new stuff to old code or just write new code that doesn't suck as much.
- toolslive 12y agoI have always thought that C++ took the wrong route here. Backward compatibility can be solved via a compiler flag too. So the language can evolve, and deprecate older sub-awesome solutions, while allowing people to still use that via a "--my-code-still-uses-feature-x-and-i-dont-want-to-update" compiler flag. You could have deprecated : - #includes and have a decent mechanism - std::pair when you introduce std::tuple - perhaps new when you have make_shared and make_unique - etc etc. There's also a gentle push towards the more recent solutions as at one point compiler vendors will not maintain these flags forever because it's no longer part of the language.
- cheez 12y agoThe presence of a language feature is already signalled via the __cplusplus define, so it is already done that way. I think C++ is very pragmatic in the way it has been done so far, but I am not looking forward to the new __* keywords for resumable functions. I think it's fair to steal the "await" and "yield" keywords back from programmers so my eyes don't bleed. I've already been conditioned to treat __whatever as a platform-specific thing to avoid in my code.