OOP in C?
Post: #1
http://www.accu.org/acornsig/public/articles/oop_c.html
Mildly interesting.
I think ThemsallTook has/had a similar stance.
Mildly interesting.
I think ThemsallTook has/had a similar stance.
"Yes, well, that's the sort of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage."
Post: #2
I've practiced that several times. You also see it quite a bit with Carbon and somewhat with OpenGL. (with texture objects, display lists, etc., but the "object" you store is actually an int that tells it which one to use) It can certainly be very useful.
Post: #3
Indeed, this is a great way to code. I'll admit I've been primarily using Objective-C nowadays, but I still like this approach a lot. It's too bad the article didn't get into subclassing... I would have liked to see if his approach was similar to mine.
Post: #4
I can't imagine "faking" inheritance in C, but you guys are the gurus...
"Yes, well, that's the sort of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage."
Post: #5
Faking inheritance isn't hard... I'd do it like this, or rather, this is how I've done it/seen it done:
Then, just use casting whenever you call functions that take the base class (when you have the superclass).
Code:
typedef struct
{
int member1;
float member2;
char[] stringy;
} baseClass;
typedef struct
{
baseClass superClass;
int subclassMember1;
float subclassMember2;
} subClassThen, just use casting whenever you call functions that take the base class (when you have the superclass).
Post: #6
Yep, I've always been fond of using OO designs even when the implementation language is C. I think you can very easily implement information hiding and seperation of interface vs implementation in C.
As for inheritance, while I do use it often, I find it to be the most abused aspect of OO languages and I don't miss having an "easy" form of it if I'm in a non OO language.
A long time ago I worked with a woman who had an entire C macro system that completely implemented v-tables w/inheritance etc behind the scenes. It was pretty slick, but it was overkill and reduced the maintainability of the code... to each their own.
As for inheritance, while I do use it often, I find it to be the most abused aspect of OO languages and I don't miss having an "easy" form of it if I'm in a non OO language.
A long time ago I worked with a woman who had an entire C macro system that completely implemented v-tables w/inheritance etc behind the scenes. It was pretty slick, but it was overkill and reduced the maintainability of the code... to each their own.
Post: #7
Who needs inheritance when we have copy and paste? 
j/k
j/k
"Yes, well, that's the sort of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage."
Post: #8Leisure Suit Lurie Wrote:I can't imagine "faking" inheritance in C, but you guys are the gurus...It isn't even faked, IMHO. The old Mac Toolbox (pre-Carbon) does it with GrafPtr/WindowPeek/DialogPeek. It is a clear case of subclassing. Replacing methods as well as inheriting them or calling the method of the superclass are nicely done with some ProcPtrs (like in SAT and TransSkel) Mac Toolbox doesn't do that most of the time though. The only drawback is that it gets somewhat clumsy to access fields in inherited classes (which is why Mac Toolbox had both WindowPtrs and WindowPeek).
The big win with doing OO this way is compatibility. Your code can easily be mixed with any other language, since it has standard C interfaces everywhere, and methods are C-style procedure pointers. Everything can cope with that. Built-in OOP extensions are generally incompatible with the rest of the world. (Standards are good, so everybody wants their own, you know.)
Post: #9
Yep, I think Ingemar's Sprite Animation Toolkit was the first time I saw object-oriented technique in a plain procedural language (It was Pascal, not C like this article, but close enough).
Chris Burkhardt
