Object oriented C programming - equivalent of 'this' keyword?

Question

I'm experimenting with OOP in C, based off of this answer. I came across something I can't quite get around. Take this example:

struct foo {
    int val;
    int (*bar)(struct foo, int);
}

int foo_bar(struct foo mod, int val)
{
    mod.val = val;
}

int main(void)
{
    struct foo foo;
    foo.bar = foo_bar;
    foo.bar(foo, 8);
}

I think it would be much simpler and clearer if there was a way to use the this keyword in C:

struct foo {
    int val;
    int (*bar)(struct foo, int);
}

int foo_bar(int val)
{
    this.val = val;
}

int main(void)
{
    struct foo foo;
    foo.bar = foo_bar;
    foo.bar(8);
}

It sounds impossible, but there may be some workaround out there, a bit like OOP in C itself. Is there any way to achieve the functionality of the this keyword in Object-Oriented C?

Answer 1

No. this keyword in C++ is a reference to the object at hand, and is actually explicitly passed to the member functions at the ABI level. Explicitly passing a pointer to the object (as the first parameter) in functions is the best equivalent in C. Note that this means

struct foo {
    int   value;
    int (*func)(struct foo *, int);
};

void foo_bar(struct foo *f, int value)
{
    f->value = value;
}

ie the pointer to the object is passed as the first parameter, rather than the structure itself. This makes it explicit that the object is passed by reference, and makes understanding and maintaining such code easier.

---

It is not sane to expect features seen in one programming language to be valid in some other programming language, even if the two are related somehow.

You see, each programming language has their own approach to problem solving, their own paradigm . Because there is no universal best paradigm possible, problems are best solved using a programming language that has the most applicable/efficient/useful paradigm. For example, you don't write a C++ program to expedite common command-line tasks; you use a shell script or other simple scripting language instead.

As a programmer, having the ability to switch from one programming language paradigm to another means you have the ability to look at a problem from different viewpoints. Looking at current software projects, the most robust, vital, and efficient ones are written by programmers who have that ability.

This is why I stated, above, that it is not sane to expect the features or paradigm of one programming language to be portable to others. You should not do that, because it is equivalent to having a single tool, and looking at all problems as if your tool at hand is the only possible tool in solving them. (If all you have is a hammer, all problems start looking like nails.) Learning, and especially learning to accept, the different paradigms in different programming languages, makes for a better programmer, better problem-solver.