11–20 of 149 posts
It had to be done a certain way, because stack conventions were all over the place, back then.
[flagged]
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…
[flagged]
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…
I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented.
You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement method polymorphism in C, which is what I said, the article linked isn't doing that anywhere, quite the opposite.
So no, C structs are not equivalent to Java classes, at all.
ADTs was a major part of the C course I took in 1998
[flagged]
You don't need macros. You either call via the vtable, or you write a wrapper per interface per message.
E.g.
struct class {
void (*vtable[NUM_SLOTS]);
};
struct object {
struct class * class;
};
typedef struct object object;
const int STRING_LENGTH_SLOT = 0;
int string_length(void * self) {
return ((int (*)(void *))((object *)self)->class->vtable[STRING_LENGTH_SLOT])(self);
}
Such wrappers are fairly trivial to generate if you don't want to handwrite them.
If you want complex inheritance patterns, you might benefit from one more level of indirection, see e.g. Protocol Extension: A Technique for Structuring Large Extensible Software-Systems (M. Franz, 1995). That paper is for Oberon, but it's easily translatable to C - did that way back.
Upside is it let's you group functionality in interfaces with less of an explosion in vtable size, downside is the cost of one extra pointer indirection.
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)
I only read a few chapters then got sidetracked, but man I learnt so much stuff from reading just a bit
i already knew all the C concepts he was using but it never occurred to me to use them in that way.
The book is very well-written and easy to understand, and also very approachable even for someone who is not so experienced with C, like myself
I want to start over someday
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…
> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented. You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement…
Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write.
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…
> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented. You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement…
OO was just a failed paradigm anyway, I’m amazed anyone would try and shoe-horn it into C in the modern day.
Earlier quoted context omitted.
> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented. You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement…
I said nowhere in that article method polymorphism is implemented. Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write.
I said
> This isn't OO until you implement some form of method polymorphism.
which means the article didn't implement method polymorphism.
> So no need to fly off the handle and accuse others of misreading something you didn't write.
So you need to pay attention at first place instead of "flying off the handle" yourself and then accusing others to do so in a useless comment.