Simulating OOP with structs and function pointers?

First of all I do not want any crap about "why don't you use C++?". I need a lot of interfacing with assembly and I want to keep it as simple as possible, that means avoiding C++ at all costs. (please no commenting on that and just go along with my wishes, it's more complicated than I'm willing to explain)

Would it be possible to define a struct in C that held value members and function points and use that as a OOP style class? I just seems to deceptively simple to work. Could I also simulate inheratence by just adding members of the super class onto the base class? Once again seems deceptively simple. Any key OOP features I'm missing besides operator overloading?

Thanks in advance.

1 - Can I define a struct that has function pointers as members? - Yes.
2 - Can I make a structure have other structures as members? - Yes.

Is that what you're asking?


Quzah.

Yes, you can. Proof of that is that the first version of Bjarne's C++ compiler didn't generate assembler, it generated C code, to be compiled by the C compiler.

Obviously, as you mention, operator overloading and templates require processing before the C compiler can take over. But all the basic features such as virtual functions and inheritance can be solved in C. Multiple inheritance gets a bit messy, and if the compiler doesn't support anonymous [nameless] structs in other structs.

--
Mats

So C++ is really just a redundancy?

EDIT:

I'm just asking this because it makes no sense (in my opinion) to use a redundant (and slower) langauge.

Quote:

---

Originally Posted by ITAmember

So C++ is really just a redundancy?

---

It brings convenience - and it has better error checking.

--
Mats

... Why don't you just use C++? j/k

Yes - what you're asking is very possible. One of the things I like about C is your style can be procedural, functional, or object-oriented. It's nice. In fact, it's my understanding that there are parts of the Linux kernel (which, like your project, needs to remain simple and use a lot of assembly) has parts that almost resemble the use of classes. I've never seen the actual code - but using C in an OOP style is certainly possible.

Question answered, thanks!

Quote:

---

Originally Posted by ITAmember

First of all I do not want any crap about "why don't you use C++?".

---

No worries.

Quote:

---

Would it be possible to define a struct in C that held value members and function points and use that as a OOP style class?

---

You can put a function pointer in a struct, but it can't point to anything by default AFAIK. So that means you can't define the function in the struct, and you will have to assign the function pointer "per object" if you are trying to use a struct like a class. So I would say, don't bother trying to emulate OOP style coding to that extent.

There is no problem emulating OOP funtionality tho. Since you are the programmer, hopefully you should be able to remember which functions do what, without having them associated as method calls. So rather that calling "mystruct.new(parameters)":

Code:

---

struct {
      char *data;
      int num;
} mystruct;

mystruct *initialize_object(char *data, int num) {     
      struct mystruct *ptr=malloc(sizeof(struct mystruct));
      ptr->data = data;
      ptr->num = num;
      return ptr;
}

---

Any methods you want "associated" with the class would just be:

Code:

---

whatevertype class_method(struct mystruct *ptr) {
        [perform operations]
        return as appropriate;
}

---

If you keep your function definitions in alphabetical order, you will have:

Code:

---

int myclass_method1(...);
char myclass_method2(...);
etc myclass_method3(...);

---

and if you are really worried C is too confusing you can put these sets in separate header files or something ;)

Sean,

Yes, Linux [and Windows] drivers use a "virtual member class" structure as the way to connect the open, read, write, and close functions of the specific driver implementation back into the generic driver framework.

--
Mats

Instead of this:

Code:

---

struct my_class
{
    void (*func1)( struct my_class *, ... );
    void (*func2)( struct my_class *, ... );
    void (*func3)( struct my_class *, ... );
};

my_class *foo = new_my_class( ... );
foo->func1( foo, ... );

---

Do this:

Code:

---

struct my_class;

struct my_class_vtable
{
    void (*func1)( struct my_class *, ... );
    void (*func2)( struct my_class *, ... );
    void (*func3)( struct my_class *, ... );
};

struct my_class
{
    struct my_class_vtable *vtable;
};

struct my_class *foo = new_my_class( ... );
foo->vtable->func1( foo, ... );

---

There is absolutely no point in wasting tons of memory keeping the function pointers in every instance of the "class."

Quote:

---

Originally Posted by brewbuck

There is absolutely no point in wasting tons of memory keeping the function pointers in every instance of the "class."

---

IMO it is silly to use function pointers for this at all.

Quote:

---

Originally Posted by MK27

IMO it is silly to use function pointers for this at all.

---

How will you implement virtuals then? Without virtuals, it's not OOP, it's just syntax.

Quote:

---

Originally Posted by MK27

IMO it is silly to use function pointers for this at all.

---

It is silly if there is no need for it - it's just extra overhead then. But if there is a need to do different things for different objects in the same outer function then function pointers is definitely the way to go. The other option is to have functions that do something like this:

Code:

---

int func(struct something *this)
{
    if(this->type = type_a)
        do_type_a_work....
    else if (this->type = type_b)
        do_type_b_work...
}

---

That gets very messy very quickly [and yes, it may be possible to use switch here, but it's not fixing the REAL problem - which is that you need to determine what the type is, and then do the work necessary]. Imagiine that you have to do this in 5-6 or more different functions.

With function pointers, you can simply call the function belonging to the struct. No messing about with if-statements.

--
Mats

Quote:

---

Originally Posted by matsp

It is silly if there is no need for it - it's just extra overhead then. But if there is a need to do different things for different objects in the same outer function

---

Just submit the instance of the struct/object to that function. That's what you're doing anyway. With the pointer, if you modify the functions parameters, you now have to change the prototype AND the function pointer in the struct. Yuck.

Quote:

---

Originally Posted by MK27

Just submit the instance of the struct/object to that function. That's what you're doing anyway. With the pointer, if you modify the functions parameters, you now have to change the prototype AND the function pointer in the struct. Yuck.

---

I don't think you understood what I meant. Say we have this:

Code:

---

struct animal
{
    void (*talk)(struct animal *this);
};


struct cat
{
    struct animal;
};

struct dog
{
    struct animal;
};

void dogtalk(struct animal *this)
{
    printf("Bark, bark!\n");
}

void cattalk(struct animal *this)
{
    printf("Meow, meow\n");
}

void dog_construct(struct dog *this)
{
    this->talk = dogtalk;
}

void cat_construct(struct cat *this)
{
    this->talk = cattalk;
}

int main()
{
    struct cat c;
    struct dog d;

    cat_construct(&c);
    dog_contstruct(&d);

    d.talk((struct animal *)&d);
    c.talk((struct animal *)&c);
}

---

Now, imagine you have half a dozen different functions, with half a dozen different animals - it gets very messy.

--
Mats

Quote:

---

Originally Posted by matsp

Now, imagine you have half a dozen different functions, with half a dozen different animals - it gets very messy.

---

What does -- it look messy already!

There is no purpose emulating OOP like that; you are in effect putting a constraint on yourself as if you had to use it. When you have something concrete you are doing, there are always a few obvious ways to customize the process.

What wrong with

Code:

---

struct animal
{
    char sound[32];
    char food[32];
};

struct dog {
    struct animal *aptr;
}

void dog_construct(struct dog *this)
{
    strcpy(this->aptr->sound, "woof woof");
    strcpy(this->aptr->food, "cat");
}

function animalspeak (struct animal *ptr) {
    say ptr->sound;
}

struct dog a;
dog_construct(&a);
animalspeak(a.aptr);

---

And of course that works if you wanted to draw geometrical figures as well?

--
Mats

Quote:

---

Originally Posted by matsp

And of course that works if you wanted to draw geometrical figures as well?

---

Really, the onus is on YOU to prove that it doesn't. ;)

Yeah, but that's not really object oriented. It's sort of function oriented. You're calling a function to act upon an object, you're not calling an object's function. Compare:

Code:

---

foo( object );
object->foo( );

---

Quzah.

Quote:

---

Originally Posted by MK27

Really, the onus is on YOU to prove that it doesn't. ;)

---

Right, you win! But only because I can't be bothered.

--
Mats

Quote:

---

Originally Posted by quzah

Yeah, but that's not really object oriented. It's sort of function oriented. You're calling a function to act upon an object, you're not calling an object's function.

---

I think that about says it.

Quote:

---

Originally Posted by quzah

Yeah, but that's not really object oriented. It's sort of function oriented. You're calling a function to act upon an object, you're not calling an object's function. Compare:

Code:

---

foo( object );
object->foo( );

---

Quzah.

---

I see no conceptual difference between the two.

OOP is OOP because of polymorphism, not the particular syntax used to invoke a method.

There are OOP languages, like ObjC, where there isn't even such a thing as a "method." Instead you have "messages." And a funky syntax involving square brackets. The syntax is irrelevant, the fact that you can send a message/invoke a method on an object and get type-specific behavior without having knowledge of the type, that is OOP.

Function pointer tables in C are true OOP. The syntax is ugly, that's all.

Then really you're saying there's no difference between functional programming and OOP. If I pass an object around and do stuff to it, there's no difference than if I have an object with its own methods? I'm pretty sure a number of people will disagree with that.

Typically people think of OOP as "an object's stuff" rather than "doing stuff to an object". As a matter of fact, pick up any intro to OOP book, and you'll get stuff like "the pizza's toppings", "the car's wheels". "car.wheels();", and not: "wheels( car )". Because the idea is to get you to think about the object, and the methods it has, rather than "what functions can I write to pass this object to?"


Quzah.

Quote:

---

Originally Posted by quzah

Typically people think of OOP as "an object's stuff" rather than "doing stuff to an object". As a matter of fact, pick up any intro to OOP book, and you'll get stuff like "the pizza's toppings", "the car's wheels". "car.wheels();", and not: "wheels( car )". Because the idea is to get you to think about the object, and the methods it has, rather than "what functions can I write to pass this object to?"

---

Let's jump ahead a bit, and say now, you have read the book already, and done lots of thinking about many objects. What can I apply from my knowledge of OOP to C programming? Well, the "inheritance" shown above (struct dog contains struct animal) is one useful thing. But methinks the use of a function ptr so you can go:

mydog.eatpizza

is perhaps not one of them.

Quote:

---

What wrong with

---

is that it is already too messy. If the only thing that makes instances different is the particular values of some data, you don't need "subclasses" at all.

Code:

---

struct animal
{
    char sound[32];
    char food[32];
};

void animal_construct(animal* this, const char* sound, const char* food)
{
    strcpy(this->sound, sound);
    strcpy(this->food, food);
}

function animal_speak (struct animal *ptr) {
    say ptr->sound;
}

struct animal my_dog dog;
struct animal my_cat cat;
animal_construct(&dog, "woof woof", "cat");
animal_construct(&cat, "purr", "mouse");
animal_speak(&dog);
animal_speak(&cat);

---

See, infinite number of different animals is possible without stupid amounts of code.

Now, what if indeed different classes needed to do different things, rather than have different data?

Quote:

---

Originally Posted by quzah

Typically people think of OOP as "an object's stuff" rather than "doing stuff to an object". As a matter of fact, pick up any intro to OOP book, and you'll get stuff like "the pizza's toppings", "the car's wheels". "car.wheels();", and not: "wheels( car )". Because the idea is to get you to think about the object, and the methods it has, rather than "what functions can I write to pass this object to?"

---

A reasonably simple search-and-replace type operation can transform A(B, ...) to B->A(...). You're saying that search-and-replace magically transforms non-OOP code to OOP code?

The syntax is immaterial. The mechanics of how the call dispatches to the appropriate implementation for the actual type, is what matters.

Quote:

---

Originally Posted by anon

See, infinite number of different animals is possible without stupid amounts of code.

---

Oh, I agree with you...you have just taken my criticism of matsp's horror show a few steps further, or rather, sketched my concept out more intelligently. I don't see any function pointers here!

Okay, let's look at this another way.

The original implementation of C++ back in "the day" was to translate C++ to C, then use a C compiler to compile the result.

Are we seriously saying that the resulting C code is somehow not object-oriented even though it was mechanically generated from C++ code?

Why are people so obsessed with syntax? It's like arguing over different numeric bases...

EDIT: Let's take it to a further extreme. C++ is ultimately compiled to machine code. Machine code clearly is not OOP. Therefore C++ is not OOP.

Quote:

---

Are we seriously saying that the resulting C code is somehow not object-oriented even though it was mechanically generated from C++ code?

---

Assembly is generated from C*, would you say that Assembly is object oriented? (I'm not suggesting it is or it isn't - just throwing it out there for thought). Personally I'd say that object-oriented programming is more of a style than a language. Some languages force it on you / make it easier more than others.

* I know - it generates machine code, but you get my point.

Quote:

---

Originally Posted by brewbuck

A reasonably simple search-and-replace type operation can transform A(B, ...) to B->A(...). You're saying that search-and-replace magically transforms non-OOP code to OOP code?

---

Will a search-and-replace make the function a member of that object? Is that what you're saying it does?

The difference between functional and OO programming is that functions exist on their own, not attached to anything specific. The OO approach ties the functions to the object, saying "Hey, this object can do this."

That is how most people differentiate OO from procedural programming. The object has the functionality, versus the function takes objects. I don't know. To be honest, I never got the whole appeal of OOP. It just seems to me like it's an attempt to make sure people don't pass stupid things to functions.


Quzah.

Quote:

---

Originally Posted by quzah

Will a search-and-replace make the function a member of that object? Is that what you're saying it does?

---

I don't know why you impart some magical quality on the syntax a->b() such that this causes b() to be a "part of" a. b() being part of a is something conceived in the programmer's mind, not an artifact of the way it's written.

Quote:

---

That is how most people differentiate OO from procedural programming. The object has the functionality, versus the function takes objects. I don't know. To be honest, I never got the whole appeal of OOP. It just seems to me like it's an attempt to make sure people don't pass stupid things to functions.

---

I don't think of it that way, at least. To me, OOP means polymorphism.

Quote:

---

Originally Posted by brewbuck

To me, OOP means polymorphism.

---

Yes, I regard OOP as the use of polymorphism through inheritance (as opposed to ad hoc polymorphism through function overloading and parametric polymorphism through some kind of template mechanism). The aspects of abstraction and encapsulation are certainly important aspects of OOP as well, but are not unique to OOP.