Question

"If you really want OO sugar - go use C++" -- was the immediate response I got from one of my friends when I asked this. I know two things are dead wrong here. First OO is NOT 'sugar', and second, C++ has NOT absorbed C.

We need to write a server in C (the front-end to which will be in Python), and so I am exploring better ways to manage large C programs.

Modeling a large system in terms of objects, and object interactions makes it more manageable, maintainable and extensible. But when you try to translate this model into C which does not bear objects (and everything else thereof), you're challenged with some important decisions.

Do you create a custom library to provide the OO abstractions your system needs? Things like objects, encapsulation, inheritance, polymorphism, exceptions, pub/sub (events/signals), namespaces, introspection, etc. (for example GObject or COS).

Or, you just use the basic C constructs (struct and functions) to approximate all your object classes (and other abstractions) in ad-hoc ways. (for example, some of the answers to this question on SO)

The first approach gives you a structured way to implement your entire model in C. But it also adds a layer of complexity that you have to maintain. (Remember, complexity was what we wanted to reduce by using objects in the first place).

I don't know about the second approach, and how effective it is at approximating all the abstractions you might require.

So, my simple questions is: What are the best practices in realizing an object oriented design in C. Remember I am not asking HOW to do it. This and this questions talk about it, and there's even a book on this. What I am more interested in are some realistic advice/examples that address the real issues that show up when dong this.

Note: please don't advice why C shouldn't be used in favor of C++. We've gone well past that stage.

No correct solution

Licensed under: CC-BY-SA with attribution
scroll top