Struggling with C coming from Object Oriented land

Question

When I am presented with programming problems, I naturally start breaking them up into logical objects in my head. Who has what responsibility, who owns what, who derives from what, etc.

I am struggling with C. I just don't get how to do things in a Procedural Language.

Can an experienced C programmer help explain how I should think about my programs during design time?

For example, I want to write my own Semaphore class. I would naturally need a Queue data structure for my program, which I would like to write myself as well. If I needed to do this in Java or C#, I could simply whip up a quick Queue class and create a new instance of it in my Semaphore class.

But in C, there aren't objects. So do I have to inline all the behavior of my Queue data structure?

Can someone help me "get it"?

Related: what is the best way to plan and organize development of an application in c

Answer 1

You can still think object oriented with C.

You just need to create a struct and a set of functions that take a pointer to an instance of that struct as its first parameter.

As for polymorphism, you can pass the size of the struct as the first member of the struct, so you know how to cast it.

There is a great pdf of object oriented programming with ANSI-C here.

Answer 2

But in C, there aren't objects. So do I have to inline all the behavior of my Queue data structure?

No.

Do this.

1. Define your class however you feel comfortable doing OO design.

2. Write the attributes of your class as a C-language struct.

3. Put that struct in a header file, along with all of the functions that operate on that struct. Make sure a MyStruct * self is the first argument to all of these "method functions".

4. Write a C module with all of the bodies of the method functions.

Poor-person's OO in C. It works well. Just be disciplined about putting everything into the struct that you need -- public and private instance variables -- everything.

Generally, avoid trying to have private variables in the first place. You don't have the full power of an OO compiler, so don't bother with low-value features like "private" or "protected".

Answer 3

I had a bear of a time moving from procedural to OO thinking, so I feel your pain.

I found that in order to learn how to create objects, it was best to think about how they would look to the caller. The same approach might help you, going the other way. Consider what the API to your component would look like. One good way is to study existing C APIs (I used the standard Java APIs as a set of examples of an OO API).

You're used to using a queue component something like this:

import some.package.Queue;

Queue q = new Queue(); 
q.add(item);

In a typical C api, you'd expect something more like:

#include <queue.h> // provides queue, make_queue(), queue_add(), others

queue q = make_queue(); // queue is probably a struct, or a struct*
queue_add(q,item);

Whenever you find yourself thinking in objects, make a similar transform.

You can use pointers to functions and the like, to make object-like structures in C - but many thousands of C programmers have managed without.

Good luck!

Answer 4

Originally C++ was just a compiler that wrote C code from the C++ sources; those were then compiled by the native C compiler, linked, etc.

Hence, all OOP methods are available in C -- it's just that the compiler won't help you, and does not provide all the compile-time capabilities such as templates, operator overrides, data hiding, etc.

1. The C++ "struct" was (probably still is) equivalent to a "class" with all members "public".
2. Member functions can be implemented as function pointers in a structure; this can provide encapsulation and polymorphism. Constructors exist in the global scope unless you're using factories. Destructors can be member functions.
3. Using accessor member functions, like getColor(), setColor() can alleviate internal differences and provide some data hiding. If you really want, you could use Brian Bondy's suggestion of hiding with macros.
4. There are actually a lot of FOSS libraries that provide standard containers -- hash tables, dynamic arrays, linked lists, etc.