If you were to extend C with some OO elements

Not that there would be much point doing that and not just using a different language.
But I thought a little about things like classes with single inheritance (achieved by replicating the same code in the inheriting class as in the base one), and I wonder about ways to implement virtual functions. I thought that for each vfunction you could just store its pointer as an additional member, but then with multiple members a vtable would make for more efficient storage. And also, I could replace the vtable pointer with a pointer to some kind of a type descriptor (which would then have the vtable), and add some type of reflection.
But the latter two methods would have to add some kind of a ``hidden'' field to the struct, while in the first one the count and location of those fields would be predictable. If I went with the ``hidden pointer'' approach, I would then need to adjust pointers behind the scenes and some other shit. I wonder how C++ does this?

Also, your thoughts. And keep in mind that I'm not some kind of EXPERT LANGUAGE DESIGNER (at least not yet), so don't get too mad.

I was most recently using Io for my OO needs. If you want to go OO, might as well go ALLLLLLL the way.

You should check out the paper "Object-oriented Style." http://www.cs.indiana.edu/hyplan/dfried/ooo.pdf It uses scheme, of course, as this is the best subset of the best language, but the ideas are very obviously applicable to what you would like to accomplish. And, yes, sepples does just use virtual method tables, which you could find out by reading wikipedia for ten seconds.

>>3
And, yes, sepples does just use virtual method tables, which you could find out by reading wikipedia for ten seconds.
As if I didn't know that, in ``I wonder how C++ does this?'', this = adjusting pointers.

>>4
Try reading wikipedia for ten seconds.

>>5
I know how to do that, but I want you guys to have a programming-related discussion, ok? :(

CUT IT OUT WITH THE FAGGOT QUOTES

>>7
What do you mean by ``FAGGOT QUOTES''?

>>6
Did you read the paper I linked? Or should you just go hang out at facebook instead?

ITT: OP is a fucking moron who doesn't know what the vtable is

ITT: OP is a fucking moron who doesn't know what OO is

ITT: OP is a fucking moron

>>1
I use C rather than C++ precisely because it *doesn't* hide these things. Inheritance and vtables are very easy to implement, add very little additional code, and conversions to superclasses is explicit. There are also far fewer restrictions; for example you can choose whether to include bases as pointers, and calling constructors explicitly allows you to construct base classes and members conveniently in real C code. This makes stuff like multiple inheritance and virtual bases easy to implement and even easier to understand.

On the other hand, C++ makes everything implicit and hidden. It's is absolutely full of *gotchas*, because you can't just see where vtable pointers are set, or what order virtual base classes are initialized in; you have to figure it out yourself on paper to see what's going on (not to mention actually understand and remember the rules, no small feat). Constructors are horribly broken mainly due to confounding allocation with initialization; initializer lists force you to use a turing-incomplete bastardization of actual C++ syntax, without even so much as local variables. Not to mention all the duplicate and incomplete syntax; for instance the new member function syntax duplicates the C style of taking the struct as the first argument, and in doing so loses support for multiple dispatch.

If you were to extend C with some OO elements
C *does* have OO elements. They work better than the ones in C++. Structs and function pointers are all you need for real inheritance and polymorphism; you don't need compiler ``help'' to accomplish it, especially when that help actually makes things worse.

>>13
How do I do all that shat in C?

>>14
I'm not >>13, but I did implement my own OO with inheritance in about 3 pages of C code. Add a few macros there for a more manageable syntax, and that becomes 4 pages of code. It's really simple once you understand what exactly are "objects" and "classes", and how "inheritance" works.

Methods are functions which operate on objects and other data. Objects are nothing more than structures. If you want to implement message-passing OO (instead of multi-dispatch OO), all you have to do is have add a vtable to the object upon creation. A vtable is an array of virtual functions belonging to that class. You may add a few fields for metadata such as object's size, or tag, or even structure if you want to go that far. Since you're writing this in C, you probably don't want to go too far with the feature-set, otherwise it may become a bit too tedious to manage, even with some macros to write the function calls for you. I prefer to keep my "OO" thinking in C, just at the "functions manipulation (possibly tagged) structures of some type" phase.



If you're using a more expressive language like Lisp, you can implement a minimal message passing system in less than a page, even though CL already has CLOS+MOP, which is likely the most advanced OO system I've seen so far, maybe even a bit too advanced for regular usage, but at least it doesn't tie methods to a single class, instead (multi-)methods belong to a generic method of one signature, and you specialize the arguments on specific classes/types, which allows one a much greater flexibility and freedom than the usual message passing system. Such freedom is not unlike doing OO in C, but it allows you to hide details under abstractions much better.


Which style one prefers is a matter of personal taste.

read the linked paper instead of reading >>15.

>>10,11
But I know and your a bunch of fagets.

>>13
Yes, I know that hiding things is bad.

And don't confuse >>14 with me.

ohok

^{Back to /b/, ``GNAA Faggot''}

<-- check em dubz