I don't use any dynamically allocated memory in my firmware projects.
I do sometimes use statically allocated pools for things like packet buffers and allocate chunks out of them, but their lifetimes are not scope based, so automatic call of constructors/destructors would not be of any help.
What do you want me to say? If nothing in your code owns a resource and needs to dispose of it when it's done, then obviously, you don't need smart pointers. I'm not here to evangelize, I'm trying to understand why someone would straight out refuse to use a language that offered more options if needed.
I'm also wondering if you've heard about std::span, given your use case. I would be surprised if you weren't rebuilding much of that functionality.
Everything around the rules of destruction in derived classes from a base class with/without a virtual destructor.
How about capture of values in a lambda within a loop? How to prevent a template expansion from killing you build process? When are move semantics sufficient for the std container classes and when are they not? What's the order of construction of multiple objects at file scope? When should a copy constructor be written so that the default shallow copy is prevented?
All of those are footguns, because if you do them wrong the program has runtime bugs without any compiler warnings.
They are all absent from C.
I'm typing on a phone, so won't go into detailw, but if you want to make such an insane claim, bear in mind that Scott Meyers himself said that C++ is too complex for him
You are not disagreeing with me when you make that claim, you're disagreeing with one of the world's foremost experts on
C++.
But you have an uncontrollable urge to write here? Someone's holding a gun to your head?
> You are not disagreeing with me when you make that claim, you're disagreeing with one of the world's foremost experts on C++.
I guess that settles everything then. Never mind that you're misquoting him.
Look, if you hadn't written the last two paragraphs, I'd have replied to your points, but they strongly indicate it would fall into deaf ears. You're clearly more interested in entertaining the peanut gallery more than actual discussion.
> I guess that settles everything then. Never mind that you're misquoting him.
I'm not misquoting him - you are free to provide a link to the context in which he said what he said.
The worlds foremost expert in C++, author of dozens of books on C++, disagrees with you. I'm merely agreeing with him.
> Look, if you hadn't written the last two paragraphs, I'd have replied to your points, but they strongly indicate it would fall into deaf ears. You're clearly more interested in entertaining the peanut gallery more than actual discussion.
The fact that you entered a thread about C practices, then got all salty when you tried to go with the "but why not use C++?" argument, then devolved into personal attacks is ... well "classy" is not the word I'd use.
EDIT: You can't respond to those points - those are all well-known footguns that are present in C++ but not in C. What were you going to respond with? "No, C++ doesn't have those!"?
Sometimes you do not want, or need, all the batteries.