This article is part of the series of educational articles for ‘Einführung in die Informatik’. Dieser Artikel ist Teil des Zusatzmaterials zu den Tutorien ‘Einführung in die Informatik’ C/C++.

We use C++ to learn all the essentials and beauties (did I really just say that?) of object oriented programming. The language supplies us with tools to create classes, methods and everything that comes with it, like inheritance and polymorphism. Based on our previous brief knowledge of structs in I call it ‘Plain-C’, we’ve developed an understanding how classes work. But can we write object oriented code in plain C? C as of 1989 had exactly 32 keywords and I challenge you to name at least 20 of them! C itself was never designed for OOP code, so I’ll meanwhile accept the challenge and try to write OOP code in plain C, let’s go!

Before we take off

… we need to know about one more fundamental what is called a function pointer. Yes, I’m aware that I cause strong allergic reactions by mentioning this four letter word. So no worries, let’s tackle it gently.

We want to talk about communication, more specifically about how Fluorescence by The VFD Collective communicates. Fast forward, you can use both USB and Bluetooth to message Fluorescence - the language is the very same (and very simple, if you’re interested).

So exactly one function is made to decipher incoming messages. But just like texting a person, some kind of feedback is appreciated. Here Fluorescence needs to know exactly whether it should reply over USB or Bluetooth. One solution is passing over the reply function. Oh wait, we can’t pass functions, or can we? Yes we can!

Functions have addresses, just like variables. We can store the address of a function just like we stored the address of a variable. Tada, we have a function pointer. Here’s a self explaining example how to work with them:

The syntax to declare a function pointer is just like any simple function declaration, except that you now have brackets around the name and prefix it with a star (*). Assigning and calling (dereferencing) is even easier if you have a look at the alternative syntax in line 26 and 27.

In Fluorescence, we have two reply functions, both taking a 10 byte unsigned char reply message buffer:

This is how the decoder works:

It just calls encoderInstance, which is passed over to the decoder as the second argument and assumes that it’s the right function. serialRoutine() takes care of passing the right function pointer:

Easy, right? Well, the syntax is awful, but function pointers are easy themselves and pretty fun! So now that we have the basics, let’s create the Student class we are familiar with in homework 7. I’ve introduced some slight changes:

A simple Object Definition

The C version is just a struct, isn’t it? Really that simple - and here is why: The data type to group variables, called attributes, is struct. And hey, that’s what a simple class without any methods is.

You know typedef? What typedef does is to replace the nasty struct Student by Student. To give you an idea, let’s look into the standard integer library stdint.h. We see that uint8_t is just an unsigned char:

More challenging: Methods!

How do we declare methods? First, this is how our complete C++ class looks like (what we know already):

How does it look like in C? Well, function pointers, finally!

See the additional this-pointer in every method? This is characteristic and absolutely necessary (I’ll talk about it in a sec). Moreover, instead of declaring methods we declare function pointers with the same name, in our example 4 getters and one toString(). Since the function pointers point to nowhere at creation, we need to link right functions to them. So this forces at least one function (constructor) to not be a function pointer inside the struct!

But before we talk about the constructor, let’s first have a look at all the other methods:

I really want you to think about where getMajor() in C++ gets to know which major we mean: It’s the hidden this-pointer to every method to let it know which object has called it. C++ hides it for convenience, but in Plain-C we can’t use the language to hide the pointer, so it’s necessary to pass it over as an argument.

Noticed the super unintuitive function name in C? I did that on purpose to prevent direct calling, as we’d like to call it from an object.

Do you know a better way to stringstream?

This is not so much about OOP in C but I’m just curious whether there is any better way to do it in C.

C++ Version of toString():

C Version of toString():

Basically I use snprintf to determine how many chars to malloc and then sprintf it into the buffer using a constant format. Since it’s better dynamic, an attribute (Student.string) keeps track of the address, and at every re-generation it’s free’d and remalloc’ed. Do you know something more elegant?

Tough Talk: Constructor

toString() in C already set the mood for how much more the plain-C counterpart can be. But simple things first:

Now C it yourself:

Here’s what it does, it’s quite intuitive actually:

• Reserve enough memory for one Student object

• Initialize all reference attributes (char *) by copying into cleanly allocated, new strings

• Linking functions to function pointers of the object, so that they become methods

• Return the new, fully initialized object as reference

Since every string and even the object itself is created dynamically in the C version, they need to be free’d before they rest in eternal peace of your DDR4 SDRAM. The destructor can be placed inside the object definition, to create a symmetry however, I prefer to keep it external. Have a look yourself:

What comes straight into your mind when I say ‘Create’?

This kind of create? Or the C++ kind?

See how similar and easy it is to create the same objects in plain C code:

An absolutely amazing thing to note is the sizes of our executable files. I’m using a MacBook Air with the latest Mojave installed and use gcc/g++ 4.2.1 to compile. While the C++ executable is as large as 40 KB, the C version is exactly 9 KB, which is about 80% smaller. I’ve found a great StackOverflow question that describes why this happens.

Also, quite interesting is that while our manually written C version uses 198 total dynamic memory allocations, C++ uses 196 with only four of them manually as you can see in the main.cpp file. Feel free to check it out on your computer using valgrind. That’s the same program I use to keep track of memory leaks. Compile on your own, download the files here:

Excited to see more?

I’m happy to tell you that there’s more on the way. We will expand the Student class written in C++ and plain C by adding inheritance. Together we will learn how to use file I/O and build a student database. Before we dive into deep pointer stuff, I’m excited to tell you something about my MP3 player project written in plain C with a lot of OOP style code and inheritance!