Simulating OOP with structs and function pointers?

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

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.

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

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.

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.

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.

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?

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.

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.

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.

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.