- I prefer functions over classes.
- no mangling of exported names, the binary is re-usable as API.
- in the long term, the C source code is more re-usable in other projects than C++ ones.
and more like this.
ps. you know you can write C++ code that is functional and use free functions primarily instead of putting everything in classes?
And once you fix it, you have built a light weight library that you can use from any other language.
Also these pointer manipulation is what gives C its power.
Then use functions?
> no mangling of exported names, the binary is re-usable as API.
Not once in my life have I seen someone use a binary as an API.
> in the long term, the C source code is more re-usable in other projects than C++ ones.
I don't even know what you mean by that.
He means that if you write your library in C it is callable from Python, Java, C++, Ruby, PHP, Python, Perl and more.
Because C++ without exceptions is not C++, and those languages cannot catch exceptions, nor call overloaded functions, nor delete or create objects using new and delete, nor refer to fields with classes, nor call methods on objects.
Write exception-free external APIs. It's not that hard.
> call overloaded functions
Write an API that doesn't overload functions?
> nor delete or create objects using new and delete
Write an API around that. You'd need to do it in C anyway.
> nor refer to fields with classes
What?
> call methods on objects
If you can call a function, you can call a method.
Your complaint is basically "you cannot write C++ in Python". Duh.
Maybe it is a complaint, but it's still a fact of life: your code is not reusable without wrapping it in C.
The reality is that C++ is not as reusable as C is: ever wonder why there are so few reused libraries written in C++, while they are so many in C?
Look on your system now - it's filled with C libraries, while the C++ libraries are probably a rounding error.
I also prefer apples over brooms.
Sometimes you do not want, or need, all the batteries.
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.
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.
Unless you're a solo developer, this is not a win.
It's no accident that C++ is the only language in which its proponents have to self police their own teams to only use a subset of the language.
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'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!"?
Simplicity beats complexity almost every time.