Object Oriented Programming in C

Related Sites

[...] You need to decide what level of OO-ness you want to support. If you want a full OO model, then you will end up manipulating pointers to functions, and implementing some name-mangling. If you do an object-based design, you get a lot of the benefits of OO but have less difficulty translating into code. Either approach is feasible and reasonable to do.

Another approach is to generate code (either manually or automatically) in C++ and then run it through a cfront translator. [...] A third approach is to use a tool to automatically generate C code from an OO or o-based design. All of these approaches work although they have different pros and cons.

[...] I agree that object based designs are relatively straightforward in C. Structs can be defined, and 'methods' that take the struct pointer as their first argument can be defined. The implementation of the structs can be hidden in .c files and their methods exposed in .h file. I also agree that you get some benefits from doing this.

However, I would not call it OO. The benefits of OO are primarily based upon polymorphism. And without pointers to functions, dynamic polymorphism is pretty hard to achieve. Unfortunately, in C, pointers to functions are pretty difficult to maintain. One needs to create initialization function that act as constructors and assign the functions pointers in each object to the appropriate functions. One also needs to adopt the convention of calling functions through these pointers. Though this is feasible, my own experience with such complex conventions tells me that they are the first things to be ignored when the schedule gets tight.

[...]

Don't entirely discard C++ for embedded work - in many ways it is ideally suited for such work. Most embedded environments allow you to use C++ or the new Embedded C++ subset.

Subsets of C++ provide very useful additions to C that do not cost you performance or make you reliant on the heap. I have successfully used it on OS-less projects that would normally be done in assembler and it saves time and helped with reuse.

I would suggest the following 'levels' depending on the 'low levelness' of your code :

1. 'pure' C
2. 1+
   • private/protected members
   • non virtual single inheritance
   • stack based classes for logging/trace
   • stack based 'auto-mutexes' etc.
   • wrappers for ugly RTOS setup and use
   • overloaded 'new/delete' memory allocation 'per class' or 'per library' memory pools to stop heap fragmentation and bound memory use.
3. 2+careful use of templates (!) A 'handle' template to auto-delete objects when they are no longer referenced is of particular use.
4. 3+STL (!) for systems with plenty of memory.
5. 4+virtual methods.
6. full C++.

At 5 you will really start to see some power as abstract base classes make testing and rework easier.

At level 6 god help you (god help me ...) :-)

Believe it or not, templates (parametrized classes) do not hurt performance, they instead tend to use lots of memory up. If your system is not very memory limited, say a Management card with a realtime OS and 16-32Mb RAM, STL is probably faster than algorithms for containers you write yourself in C and is less error prone.

Paul Field, Object Oriented Programming in C

Embedded C++

Bruce Powel Douglass, Real-Time UML: Developing Efficient Objects for Embedded Systems

Bruce Powel Douglass, Doing Hard Time: Using Object-Oriented Programming Software Pattern in Real Time Application