Try
https://www.cs.rit.edu/~ats/books/ooc.pdf
https://www.codementor.io/michaelsafyan/object-oriented-programming-in-c-du1081gw2

At some pain level you can basically achieve object-oriented programming in C. At extremely high pain levels you can also reach full enlightenment, but you can save a lot of time/money/work by using somebody else' solution.

Ultimately, object-oriented design patterns that rely on object-oriented semantics only work in object-oriented languages. Understanding the primitive reasoning behind the pattern and working out how to apply it to a C program is an exercise for the reader. There is no perfect 1:1 mapping. Some things cannot be done in C without great pain, which defeats the purpose of the pattern (it's only useful if it's reliable, and it's only reliable if it's mostly automatic).

Fortunately, several people have already gone through this pain, and you can use their work by picking up an interpreted language such as Perl, Python, or Ruby; most of which are ultimately implemented in C. That's not really the same thing as you're requesting, but what you're requesting doesn't really make sense, and perhaps the answer you needed to hear to it was just this one.

Thank you all for letting me know that it's not my fault that it seems to be difficult to write programs in C, especially bambam (if it's really what they call you).

I just wanted to write a simple software in C to teach it to some students, now I will make it and will try not to do the same again, especially when writing the same thing is easy in C++.

Nitehacker, it's not rocket science and I know that writing code in C saves some time because you don't have to write classes but writing classes mean less messy code and I won't have to take the hassle to restructure my code every time it gets bigger than I originally I thought it would get.

That more or less seems to be the case from what I remember about C++. If you're going to be writing all functions to accept a structure for a parameter, you're doing explicitly what C++ does implicitly with objects.

Audric, you are spot on.
That's what I was trying to say but said something else entirely.

Well, all is well if the end is well.

{"name":"611999","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/6\/f699b3048548b6702cb100e14bc4483a.png","w":1279,"h":684,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/6\/f699b3048548b6702cb100e14bc4483a"}

@jmasterx : Even people who do use this pattern (correctly) may try to overengineer it. For example, "I want foo.c file to only contain files that take a FOO* argument, like the methods of a C++ class. - And now which file should hold the function transfer_item_from_room_to_backback(ITEM *itm, ROOM *room, BACKPACK * backpack)" ?

Yes, but you intend it to organize (and regroup) code by purpose. Someone who is only used to OOP may see the "composite pattern" of this specific combination of classes (item-room-backpack), and balk at the idea of using the same C file for functions that handle different combination of classes (item-room, item-inventory, item-item)...

People who have only learnt OOP don't realize that in a language such as C you often organize by process (verb) instead of data (noun) : display_player(PLAYER*) and persist_player(PLAYER*) in display.c and persistance.c respectively, rather than everything in player.c

I like to use both ways, even in OOP.
In OOP I might have an item manager that listens for collisions between items and the player and puts the item into the backpack. (well, it would probably be some kind of scripting practically but you get the idea).

I like the idea of having mediators to handle interactions between objects.

eg: PhysicsSolver outputs collision events, observed by the item manager which could consume certain collision events.

No, you're probably right about that. But...

This was basically my main point. If you're going to use C, use C, don't try and imitate C++. If you want C++, use C++.

Personally, I prefer C, but I always say that the best programming language is the one you are comfortable using. Unless of course you're in a team, then you all have to agree on something.

There are a few aspects of C++ that I do like. Vectors are very nice, but rather than use C++, I created my own vector-like functions in C for my own use, mainly because I enjoy the challenge of programming them. Turned out it wasn't that difficult. You can see some of this in my Deluxe Pacman 2 source. I wanted Vector stack style functionality for my path finding, so I wrote my own that is fairly portable in C.

Interesting discussion anyhow. I am about the same, there's no reason why we can't have the best of both worlds.

You'd probably like kotlin then.

Allegro 5 has a vector type too - https://github.com/liballeg/allegro5/blob/master/include/allegro5/internal/aintern_vector.h