For my target space, there's a few rules for c++.
Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in some instructions and code to support these features that can cause issues in low level environments.
Things to learn (All work in the kernel):
A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types the same way a macro would.
B. Use RAII.
C. Use constructors and overloading.
D. Zero pointers should be exposed to code except where absolutely needed. If you need to pass by reference, use the c++ style.
E. All allocations should be wrapped in a class with RAII. You can overload the operators on the class to make it seem like a pointer so you can still do if(!RAIIPointer).
A good video on kernel c++ is here https://www.youtube.com/watch?v=AsSMKL5vaXw . You can use a surprising amount of C++ language features in the kernel and it makes it extremely smooth and safe if you do it properly.
You can do some nifty stuff like generate CRC lookup tables at compile time without hardcoding them.
I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics.
Perhaps controversial, I've also found (especially bare) lambdas and even std::function objects useful, although may evolve into something purely static when the dust settled. Highly dependent on target of course.
It will be interesting to see the final form of the new MISRA std, since the active one predates all of this.
std::vector
std::list
std::map
std::unordered_map
std::set
std::unordered_set
std::sort
std::transform
std::merge
std::string
std::regex
std::swap
std::function
std::stable_partition
But there are much more than that in STL.
> A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types
"Avoid STL due to bloat but embrace templates" doesn't make sense to me. Isn't that exactly what code bloat is? Too much code generation?
If you want to write bare metal C++ then this page from the above tutorial will be useful https://www.avabodh.com/cxxin/nostdlib.html
> This open-access course is directed at those who are already familiar with C
> and object-oriented programming towards a proficiency level of C++
> programming.I agree with Kate Gregory that this is a bad way to teach C++ from scratch. That is, if you know only say, Python or Java (or nothing) and want to learn C++, you should not begin by learning C. Kate's approach skips many of the things you can do in C++ but you shouldn't, whereas if we try to start with C you're going to see that a lot, because "they were legal in C" is why they're allowed in C++ even though they're a bad idea and then you have to unlearn things. You're maybe expecting some of that if you've years of C programming experience, but there's no need to introduce an idea on Monday only to tell students on Tuesday that it's a bad idea and they must never do that.
The most insidious cases are where something is legal and correct in C but it's wrong in C++ yet it will compile and you maybe have broken software. There are some nasty type punning examples, where the pun was an idiomatic C expression which does exactly what you wanted, but in C++ that's Undefined Behaviour and all bets are off. You'd just never teach those type puns in a pure C++ course, they're never the Right Thing™.
I definitely think Bjarne Stroustrup's book about his own language isn't very good, even in later editions (which correspond to a more modern language) and so I would avoid buying that, I'm not sure it's a good defence of the language as an idea and I'm sure it isn't an effective tutorial, even if not for being out-of-date.
I always look askance at folks who say they know C++ but not C. The C++ abstract machine is built over the C abstract machine and it becomes even more clearer when you go down to the binary level.
Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.
"Less important" maybe but not "negative".
You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive. It is also easier to learn C++ as a "better C" in the beginning else it becomes overwhelming. I believe this is the main reason most beginning C++ programmers find the language "scary/difficult/huge/overwhelming/confusing". They are trying to learn everything at the same time which is an impossibility with a language as baroque as C++.
However there is a huge amount of C code and programmers who would like to move to C++ and it is for them that the techniques of C coexisting with C++ are very relevant. There can be no wholesale rewrite of the code into C++ but a gradual rewrite module by module and as needed. Using C++ as a "better C" is the path here.
But this isn't so much like C, where raw pointers often express ownership.
You aren't going to really learn "everything" in C++ anyway, regardless of how you approach it, the language is a vast sprawling mess, the fact somebody wrote a serious book just about initialization [https://leanpub.com/cppinitbook] in C++ gestures at the problem. Freeing themselves of the need to have a language which is well-defined, or which can be demonstrated to be sound, or really follow any principles whatsoever was doubtless briefly convenient but the result is unmaintainable nonsense.
As a diehard proponent of Rust your views on C++ are well known and there is nothing new here. But the fact of the matter is that the industry runs on C/C++ and the main reason is due to its baroque set of features whatever one may think of them.
There are resources oriented toward embedded C++ that address these (at least memory allocation.)
On a project a couple years ago I was pushing to use C++ instead of C, if only as a "C compiled using the C++ compiler" for better type checking. I could not convince the project lead, who's technical depth far exceeded mine, that the C++ compiler was as likely as the C compiler to produce correct translations.
2) Software Architecture with C++ by Adrian Ostrowski and Piotr Gaczkowski. - Gives the overall picture of how to use C++ plus relevant modern tools as a complete development system.
3) The C++ Programming Language by Bjarne Stroustrup. - The bible/reference with programming techniques for the language.
Learning C++ is not difficult and don't let the size of the language intimidate you. Survey the different ways of programming in C++ i.e. Imperative/Object-Oriented/Generic/Meta-programming and use them as needed in your project without trying to master everything; that will only happen over time as you gain more experience.
In general, also, I have found that it is wise to learn C++ socially - i.e. participate in Open Source projects, as you learn/study/contribute/assist other C++ developers, on a semi-regular basis.
I've learned a lot about what I would call "decent C++ code" (i.e. shipping to tens of thousands, if not hundreds of thousands of customers) from such projects. I would suggest finding an open source C++ project, aligned with your interests, and study the codebase - as well as the repo history (i.e. gource) - to get a productive, relatively effortless (if the interests align) boost into the subject.
(My particular favourite project is the JUCE Audio library: https://juce.com/ .. one of many hundreds of great projects out there from which one can also glean modern C++ practices..)