I feel like C exists at a level below such concepts. Simply being able to define a function `void do_stuff(struct mystruct *obj)` opens the door to object-oriented style programming. A lot of people seem to define OOP by the presence of superficial stuff like inheritance, polymorphism etc, but really those are additional concepts that aren't useful for every program. The real difference is mutating state on the heap. So you could say C is an object-oriented language, by default, because it doesn't stop you doing this stuff, unlike a higher-level language like Clojure which simply doesn't have mutation (for the most part). Or you could say C is a functional language because if you don't explicitly pass pointers then you get copies. Really it's both and it's neither. It's whatever you want it to be.
That you can do functional or OOP in C does not make C either kind of language, it just means that C is flexible enough that you can make the computer do things the way you want it to, no matter what that means, and other languages purposefully prevent you from doing what you might want to do.
C++ is object oriented not because it has compile time support for polymorphism or any of that other bad programming practice, but because classes have code sections that live with them, whether on the stack or in the heap, that can operate only on memory belonging to that instance of the class.
Object oriented programming is a coding style and choice. Some languages make it a first class part of the language design. It is purposefully not part of C.
However you can do OOP like things in C: a popular paradigm is to pass around pointers to structs that (should) live in the heap, and to have a number of functions which work on these structs. This is very similar in practice and mental modelling to OOP as users of C++ might know it, but is distinct in that no code ever lives in the stack or heap, and no code is restricted from operating on any of the program memory.
Hmm. In what sense do you believe that class has a code section that "lives" on the stack or heap?
On a modern system you can't usually do that because of W^X rules (also on a non-x86 modern system the performance would be abysmal if you tried because why waste transistors supporting something only crazy people would want?)
So perhaps notionally in the abstract machine if I have sixteen Clowns in a C++ vector there are sixteen copies of the Clown method squirt_water_at() in the vector too, but I assure you all the compiler emits is one copy of squirt_water_at() for Clowns, to the text segment with the rest of the program code, and maybe if Clowns are virtual, a pointer to a table of such functions lives with each Clown just in case there are Jugglers and LionTamers in the vector too - although compilers can sometimes figure out a rationale for not bothering.
Regardinf W^X, doesn’t the Linux kernel has some optional expensive debug operation that can be turned on/off through a self-modifying code removing the expensive branching?
I mostly agree with you. But "or any of that other bad programming practice"? Polymorphism is not a bad programming practice. Yes, it can be misused. No, that doesn't make it bad in and of itself.
Yep, can definitely do OOP in C. Except over here in embedded land those structs don't live in the heap... but as globals (still referenced via pointers tho).
Was demonstrating the difference between inheritance and composition in OOP C to my junior dev just this week.
No, mutating stuff on the heap is not the real definition of OOP. That's the definition of "mutable" programming, which is not a term that we use a lot, but it obviously is the opposite of "immutable" programming, which is where you can't change stuff on the heap.
Sure, they all support mutation. So do languages that are clearly not object oriented, like, say, ALGOL-60. (You can do mutation in Haskell, too.) So "mutation" is at least somewhat orthogonal to "object oriented".
What is object oriented? It's worse than "you can find an OO language that doesn't support feature X". There are (at least) two schools of OO, and they define OO differently. There's the Alan Kay school, where objects are independent entities that send messages to each other. And then there's the C++/Java school, where objects are less independent, and they call each other's functions.
What both of those have in common, though, is the idea of an "object", which is a bundle of a data structure plus code. In general, the associated code is the only code that can modify the data in the structure. (Yeah, I know, public data. But if you do that as your normal approach, then you're not really doing OO, you just have a bunch of structs that anyone can modify.)
An OO language, then, is a language that either supports or requires OO programming. Java, for example, requires it - a function has to be a member of some class. (Yeah, I know, it could be static, and it could not operate on any of the data of the class. Java still forces you toward OO more than C++ does.)
What about something like C? It lets you create structs, but it does nothing to let you restrict access to "associated" code, nor does it give you a way to associate code with the structure. (Yeah, I know, file static.)
I keep saying "yeah, I know" as I admit the exceptions to what I'm saying. None of this has rigid, clear boundaries. Still, there is a set of things that are generally OO, and a set of languages that generally encourage and/or support programming that way.
> What both of those have in common, though, is the idea of an "object", which is a bundle of a data structure plus code. In general, the associated code is the only code that can modify the data in the structure.
But you can do that in C. The argument for C not being object oriented is that it does allow you do stuff that isn't object oriented, but you just said yourself that even so-called OO languages allow you to do that anyway.
Object-oriented programming is a thing that C lets you do. It's fine if it lets you do other things too.
You should check out Common Lisp's CLOS which is the best object-oriented framework I've ever used. It's nothing like the "bundle of data structure and code" you describe.
Well, no, C lets you do that stuff completely manually. C is not object oriented because it gives you zero help in programming in an OO style. It doesn't forbid it, but it doesn't forbid much of anything.
As opposed to C++, which gives you a bunch of tools to help you, and to Java, which forces you.
I feel like C exists at a level below such concepts. Simply being able to define a function `void do_stuff(struct mystruct *obj)` opens the door to object-oriented style programming. A lot of people seem to define OOP by the presence of superficial stuff like inheritance, polymorphism etc, but really those are additional concepts that aren't useful for every program. The real difference is mutating state on the heap. So you could say C is an object-oriented language, by default, because it doesn't stop you doing this stuff, unlike a higher-level language like Clojure which simply doesn't have mutation (for the most part). Or you could say C is a functional language because if you don't explicitly pass pointers then you get copies. Really it's both and it's neither. It's whatever you want it to be.