5 ms·
You wish. Unless I'm terribly misinformed, "modern C++" contains all of the features of the prior versions, which means that in the real world you have to lear
by downerending 7y ago
You wish. Unless I'm terribly misinformed, "modern C++" contains all of the features of the prior versions, which means that in the real world you have to learn and deal with all of it.
- jfkebwjsbx 7y agoThat is the point of backwards compatibility. It is a feature, not a bug. Whether that feature is a good idea or not and to what degree, is the question.
- Quekid5 7y ago... but it's worth considering that this is a 'question' from 2010. Just saying...
- downerending 7y agoI'm not saying it's a bug. I'm saying that backwards compatibility means that you still have to deal with all of the historic flaws of the language today. The article is indeed still relevant.
- UncleMeat 7y agoBut that’s true for literally everything. If you have a cpp code base and are building new stuff in rust to interop then you still have legacy cpp code even though rust has fewer problems.
- KptMarchewa 7y agoNot really. Legacy stuff can be contained. For example, you could specify language version level in file and it would disable removed/deprecated stuff.
- UncleMeat 7y agoLinters can prevent you from using outdated C++ constructs with ease.
- saagarjha 7y agoNot everything; see for example std::auto_ptr.
- downerending 7y agoInteresting (and also another thing to know). Is there a list somewhere of features that have actually been removed from C++? (i.e., that would cause old code to break)
- saagarjha 7y agoHere’s a list for C++17 and C++20, at least: https://mariusbancila.ro/blog/2018/07/05/c17-removed-and-deprecated-features/ https://mariusbancila.ro/blog/2018/07/05/c17-removed-and-dep...
- rumanator 7y ago> which means that in the real world you have to learn and deal with all of it. That makes as much sence as claiming that to develop software in, say, Python on the real world you have to learn and deal with all of its standard library. That is not the case. That has never been the case ever for any programming language, be it large or small. Specially in C++, where since it's inception the standard approach is to, at best, adopt a subset of all features and stick with it.
- tonyedgecombe 7y agoMaking a language so big and complex that you can't expect to understand it all isn't a good idea. You might be able to get away with using 50% of the language but if some project you depend on uses a different 50% then you have a problem.
- rumanator 7y agoIMHO C++ is unfairly singled out with regards to it's extension. That criticism rings true if applied to pretty much every single programming language ever devised, including "small" languages such as C.
- downerending 7y agoC, even today, fits entirely in my head. C++ does not. I suspect this is not an uncommon situation among programmers.
- 2zcon 7y agoOK but if you're a competent, adult software engineer it should be fairly easy to overcome that problem.
- tonyedgecombe 7y agoThen why is it so common for people to try and select a subset of the language. Arguing about what people should do is pointless, you have to look at what they do do.
- gumby 7y agoI don’t really understand your point. Just because all the implementations support the `asm` keyword doesn’t mean you need to know the assembly language of every CPU that has a c++ compiler. You can write your code in modern c++ and ignore prehistoric carbuncles (some of which have been deprecated and eliminated FWIW). And you can call external code written in older dialects without having to look into its source code.
- downerending 7y agoThat's great for a greenfield project where you're the only developer. If it's multiple people, you have to deal with whatever subset the powers-that-be on your team wish to use. If it's not greenfield, you have to deal with the subset exists in the codebase. And if you're a Dirty Harry type like me, debugging issues with dozens of disparate codebases written in various crap subsets, you pretty much have to know the whole cursed thing.
- Ragnarork 7y ago> which means that in the real world you have to learn and deal with all of it. This is not what happens in the real world though. While I agree that you have to deal with whatever is in your codebase at a given point, it also doesn't imply that you have to use everything and that everything can be useful for your project. As standards keep coming and features get added, it's still increasingly prevalent to see guidelines and awareness around the topic of choosing your own subset of C++ to work with. The main drawback is mostly that it incurs a cost in terms of brain power to discipline yourself to keep your work within a restricted set of language and standard library features. It's extremely rare (and even debatable) whether a single person masters all the aspects and features of C++ (and if there's one, it's probably Alexandrescu).
- downerending 7y agoIn my world (see other reply), I get to deal with whatever is in dozens of codebases written in many times and places. The superset of everything they're using is pretty much everything. Beyond that, even the "good" modern subset of C++ is crazy complex. I've sat in a room with some of the better C++ programmers in the world while they study and try to comprehend the new features like rabbis interpreting the Talmud. If there's one concise, fundamental rule of software engineering, it's this: Complexity kills.