面向对象的 C 类代码 - 不带参数的调用者识别

Question

If I have this setup:

#include <stdlib.h>
#define NEW_FOO ((foo_t*)malloc(sizeof(foo_t)))

void foo_func(void);

typedef struct {
    void (*foo) (void);
} foo_t;

int main(void) {
    foo_t *a = NEW_FOO;
    foo_t *b = NEW_FOO;
    a->foo = foo_func;
    b->foo = foo_func;
    a->foo();
    b->foo();
}

void foo_func(void) {
    // determine wheter a or b was called?
}

Can I then find out, wheter a or b was the caller of foo_func , strictly without a parameter like self , this , ... ?

The return address should be on the stack, so you should be able to identify the caller somehow, no?

I thought of a possible approach (it builds upon the idea above): The first time the foo_func is called (maybe through an initialization function, but let's leave that out to keep it simple) through a->foo() , store the address of struct a in some sort of array of pointers, I would assume. Same with b->foo() . Then, anytime that a->foo() or b->foo() is called, you would compare the address of the caller struct with the contents in the array to identify wheter it was a or b that called foo_func() .

It's just that I have no Idea if and/or how that is possible, so if anyone of you could help me with this, I would be very glad!

Answer 1

I guess you're annoyed about the unsightliness of constructions like:

a->foo (a, arg0, arg1);
b->bar (b, arg0);

Unfortunately, the style of programming you've adopted does force this style on you, if you want to implement a simulation of polymorphic methods. Maybe you can implement a set of macros so you can write something like:

METHOD_CALL2 (foo, a, arg0, arg1);
METHOD_CALL1 (bar, b, arg0);

and so not have to repeat the "object" names a , b , etc., in the call. I've seen this done as well but, in my view, it doesn't look any prettier, and I'm sure it's no more maintainable.

As this is C, not C++, in the end you're going to have to have some way to pass your equivalent of this to the "methods" in your implementation. You might be able to disguise it with macros and variable-length argument lists, but it's going to have to happen somehow.

But why worry? This is idiomatic C code -- every application and library that takes an object-oriented approach to C will be using constructions of the form you want to avoid. People will understand what you're doing. Trying to disguise it will not make your code easier to follow, I suspect.