The best way to learn a new language is to follow a proper structured resource which would cover syntax, semantic, tooling & ecosystem and best practices.
And that's the usual fallacy (just ignore the bad stuff).
But if you work with C++ in professional context, you will encounter it somewhere (library, teamate's PR, legacy code, LLM output, book / blog / conference ...). |
You actually need to know the bad stuff to be able to judge it and discard it.
- new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less<> key for transparent lookup in maps)
- new features not usable by the layman (coroutines ...)
- Cryptic syntax (reflection...)
- Stuff you are told not to use because of performance reason and that cant be fixed because of ABI (regex)
- Compile errors that are 1km long (no, concepts are not helping here, the 'nicer' message is still buried into a hot pile of template instantiation callstack).
We are more likely to have water and food shortages because of resource exhaustion and climate change. Maybe goods shortages because of war or economic depression.
Dissimilar redundancy eliminates that risk. A completely different OS, different codebase, different development team.
Not entirely true. I've heard during my uni years of a case were two independent teams used the same textbook for implementing a feature, which had an error, and thus resulting in the same failure mode.
Yes, I'm working on FAA SWIM services now.
The tech feels old school (UML, XSD...) but having documentation, class generation from XSD is very helpful.