131–140 of 149 posts
Earlier quoted context omitted.
All you need is a field in the struct to point to your vtable. Please try to think more charitably and not be so aggressive. Even if the author was wrong, which they aren't, doesn't mean they don't have the kernel of a good idea. Charitability is not a tool merely for being nice to others, but being nice to yourself. You learn more this way.
[flagged]
I'm just curious what I plagiarized.
Earlier quoted context omitted.
If you're writing C, you'll be writing much worse than that on a regular basis. There's a reason I rarely use C any more. But of course if you're going to reimplement OO from scratch in C you will see the entire machinery laid bare. You're only doing it in the first place either because you're committed to using C for whatever reason, or to understand OO implementation strategies.
Replying to myself to leave this here, since it's vaguely related. If anyone really want to have nightmares about OO'ish concepts in C, here is a few different ways to implement closures in C, going from relatively straightforward, to (unportable) runtime generation of assembler thunks: https://hokstad.com/how-to-implement-closures
I've seen OOP inheritance in C before. It involves a table of pointers to functions, and a derived "class" would just point to a different table. It works, but all the machinery has to be handled manually. It's very, very easy to make a mistake. The question is, why do this? Just use C++ as "C with classes" and you'll be much better off.
and the question: "so much manual/repetitive work, why do this"... is still valid.
Earlier quoted context omitted.
I’m too old and tired for the insult slinging anyway. What’s my fundamental misunderstanding? What’s the straw man? Class == re-use? I don’t hate OO by the way, it’s just not the first, only, or in my opinion best way to think about or structure code. I do think the expectations that OO would bring increased productivity, code-reuse, etc were not realised and hence why I referred to it as a “failed paradigm”. Not bec…
I can agree with a lot of what you wrote, and especially outcome vs. the original OOP promises. They meant one thing, and it turned out that thing is actually an anti pattern (inheriting implementations and state, not merely inheriting interfaces), but then they also delivered on what they said, just in a different way. Example: "we will have reusable code!" What they meant was deep inheritance hierarchies where chil…
I have previously worked on very large C code bases (10m+ loc) that were well written. I haven’t worked with the Linux kernel, but the “SOLID Principles” and “modifiable and extensible subsystems” certainly were evident in these code bases. You claim that this form of programming came as a result of the study and practice of OOP, but I think this cannot be right. The ideas pre-date this. These code bases, pre-date this. Much of the literature from the 70s covered these topics.
I think what happened through the later 90s/early 2000s was that OOP was universally embraced, but without theoretical backing. C programmers picked up C++ (I was one), without really understanding, and the result was a mess. From there I think good practices were rediscovered, not invented. I don’t credit OOP for the good practices, although I don’t disagree that some truly new things have been learned.
However, I still have to deal with the poor practices within OOP. Developers inherit all the time for convenience. Rarely do they think in terms of interfaces/contracts at the modular level (why is this class public? *shrug* why isn’t this class sealed? *shrug*) It’s this sort of thing that makes me annoyed at OOP. To this day, developers still sometimes think of every class they write as being a “reusable” component, and this I lay at the feet of OOP.
Classes and Objects are sometimes useful. That’s what I think of as OOP, and that’s the bit that I don’t see as very valuable.
The famous htop actually employs OOP in C. https://github.com/htop-dev/htop/blob/650cf0f13bf667270d0a6a...
(GObject is of course also object-oriented, but IMO hardly counts as C programming in how it works, it’s more of a separate OO language hand-translated into C—Vala is basically that language, finally implemented years later.)
Earlier quoted context omitted.
Hi. For background, I have been writing professional OOP code in ANSI C. Yes, Structures in C can be used as classes. And yes, this includes polymorphism. My solution was to put a callback in the structure that would point to the implementation that was polymorphic. This allowed me to pass the struct around and then call the specific implementation at the right time. When you write OOP in C you do not need to make it…
>My solution was to put a callback in the structure I think you mean function pointer. But yeah, that's the usual way to do it, although a bit wasteful in terms of memory compared to a vtable (but needs one less indirection to jump to the method).
For me, a callback, is when you have two modules and the function pointer is used to call back the functionality from the calling module in an environment and at a time determined by the called module.
A polymorphic method is a callback used in a certain way in context of OOP. You have a callback from one module (the implementation) passed to another module that can call potentially many different implementations through the same interface (which makes it polymorphic). This callback is tied to the structure by the calling module, which makes it a method. You may have language support and have entire mechanism hidden from you, but this is essentially what is happening. A pointer to function that is passed to another module for execution.
Now, when you do "manual" OOP in C without building your own vtable macros and such, I think "polymorphic method" is a bit too much and "callback" is more fitting.
Earlier quoted context omitted.
I can agree with a lot of what you wrote, and especially outcome vs. the original OOP promises. They meant one thing, and it turned out that thing is actually an anti pattern (inheriting implementations and state, not merely inheriting interfaces), but then they also delivered on what they said, just in a different way. Example: "we will have reusable code!" What they meant was deep inheritance hierarchies where chil…
I think we have been talking past each other to some extent. What you are defining as OOP is not what I think of as OOP. The concepts that you are referring to as valuable I agree with, I just think they are independent of OOP. I have previously worked on very large C code bases (10m+ loc) that were well written. I haven’t worked with the Linux kernel, but the “SOLID Principles” and “modifiable and extensible subsyst…
"OOP has failed" should be read in context of the promise that everything can be effectively implemented with OOP, that you can make objects for everything and your entire program built out of it. The masses adopted it with pretty poor results -- and the poor results prompted people to say that "it has failed".
It just means that it has failed to live up to its promise. It does not mean OOP is not useful. Quite opposite, we have learned a lot about when it is very useful to use OOP. And also when it probably is a poor idea.
I personally mix and match OOP and functional styles. I will typically create objects to describe domain model because it is super useful to talk about operations on entities. But I will call these objects from functional context where it makes much more sense to create infrastructure from functions that can easily deal with different types of data.
No programming paradigm is clearly better than others and no programming paradigm is without flaws.
I would strongly suggest treating every person that says otherwise with extreme caution -- people tend to say these things at certain stages of their evolution as programmers until they have enough time to learn ins and outs of all things.
Earlier quoted context omitted.
[flagged]
"plagiarized argument" I'm just curious what I plagiarized.
You perfectly understand what "passive-aggressive" means. Just don't go around patronizing people like that, nobody died and made you god.
While I commend this effort I should say that seriously, just write C++ if possible. No matter what you do memory management is going to be your biggest enemy (I’m ignoring the aesthetic aspects like macros, function pointers, type safety, etc). Without RAII it’s just not worth it. Just choose the simpler portions of C++ and keep safe.
You can do RAII in C. You still have to define a dtor function. https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
A whole book on this topic was already written in 1993 by Axel-Tobias Schreiner. It seems to be freely available nowadays: https://www.cs.rit.edu/~ats/books/ooc.pdf (edit: link updated to point to author's website)
Years ago, I started an implementation of that book: https://github.com/linkdd/ooduck Never truly finished it, but it works well :)