If you want a good example of full-fledged OOP in C, take a look at GTK+. Mostly, your constructors have a lot of boilerplate to initialize things like vtables and keep track of a type hierarchy. Creating your own object for GTK+ is a good way to learn what most OO languages do for you behind the scenes.

One thing you’ll learn by writing some real code is that virtual methods are not as common or necessary as you would think they’d be. Programmers have a tendency to overuse inheritance. Most of the time, you know exactly which static function you need to call, and you’re just sharing a simple data structure between several different functions. You extend it simply by creating a new function that works on the same data structure. This is how the vast majority of procedural code works.

When you do truly need virtual methods, you just add function pointers to that data structure you pass around. Then perhaps create a wrapper function to encapsulate the ugly function pointer syntax. See here for an example of how that’s done in GObject, the object library of GTK.

If you need to potentially add fields, that data structure you pass around typically has a void* or something where you can store implementation-specific data.

Again, write a real app in GTK+ as a learning exercise, and I think you’ll find the patterns somewhat familiar, once you get past the syntax.

I think the easiest way to understand this is by looking at a simple example in C: the qsort function of the standard C library. As a user of that lib, you can provide an arbitrary comparison function to qsort here without touching or recompiling the library.

Another good example was shown in this former SO post. It exaplains how to build the equivalent of a String class in C, and how to emulate inheritance.

This recent blog post by Bob Martin is relevant. In it, he defines providing convenient ways to implement polymorphism as being the essential element of what makes a language object-oriented.

In light of this, we can read your question as “how do I do object-oriented programing in a non object-oriented language?” The answer to this is quite simple: you don’t if you can possibly help it. Yes, it is possible to implement it in many such languages, but the results are always unpleasant and difficult to read or work with. If your problem involves the need to handle different types of data in similar ways (i.e. if it is essentially a polymorphic problem) then use an object oriented language. If you have to work in a non-oo language, try to unify your data such that you never need to handle different types at the same place in your code. Learn to worry less about repeating yourself: it’s much harder to avoid in non-oo code. And use function pointers as a last resort, when you absolutely need them only.