(C) 2009 Hank Wallace
PREVIOUS – Embedded System Design Library: Language Features
NEXT – Embedded System Design Library: Debugging
This series of articles concerns embedded systems design and programming, and how to do it with excellence, whether you are new to the discipline or a veteran. This article explores the advanced features of C and C++ (as an example), and why you should avoid them.
Though C++ is an object oriented language, 99.99% of programmers still think procedurally. This results in programs which are collections of object frames loaded with procedural code. So it looks like an OO program to the managers, but it’s really just a load of function calls like any K&R C program. Programmers STILL think in terms of sequence of operations, not objects, operators and methods.
Some programmers latch onto features of OO languages and use them to the detriment of the code. For example, take templates. I looked at another programmer’s code while sniffing out a bug. The main *.cpp file contained about 15 lines of code referring to a template. Most of the code was in a header file, about 3,000 lines worth. This program was written as a huge template, and instantiated once to make the program go. Confusing to say the least.
That template was so specialized that it would never be reused. Just write the code you need to write!
Another thing this program did was extend basic operators. I saw the ‘+’ sign being used to manipulate data structures in unusual ways, for example. In one section of code, there were uses of ‘+’ to add numbers, concatenate strings, and manipulate data structures, and it was not terribly obvious what was happening at all times, without referring to the header files continuously. I had this nagging question in the back of my mind, what other operators have been redefined?
If you are tempted to extend an operator, DON’T. Use the neanderthal technique of employing a function, named descriptively, to accomplish the action. It may not make you feel as sexy and powerful, but it’s far easier for others to understand. After all, our objective in reading your code is NOT to admire your brilliance, but to fix your mistakes, and then get on with our lives!
A feature of K&R C that not many programmers use is the function pointer. I was debugging and testing some open source PPP code a few months back. There was one state machine implemented for the various layers, and each layer’s layer-specific code was represented by a set of function pointers. The main routine set these function pointers for each layer, then called the state machine, sending it an array of function pointers.
That’s cool for code compactness. One state machine, multiple layers. Highly intelligent. Except for the fact that debugging the code was impossible! OK, which layer are we running now? What does that pointer point to? Which function? Setting a breakpoint in the state machine resulted in breaks for calls from each layer, and it was virtually impossible to tell which layer was running. ARGGGHHHG!
That PPP code was a good example of a write-only program, impossible to decipher after the fact. If you need a function pointer here or there, no problem, but I’ll bet there are 10 other ways you could solve the problem efficiently.
Look, we need to think and code in common sense terms that others can understand without having to be experts in esoterics. Avoiding the advanced features of languages helps in that regard. Don’t let others make you feel inferior because you don’t use arrays of virtual functions employing overloaded operators instantiated by templates. Those guys cannot get a date, anyway.
Author Biography
Hank Wallace is the owner of Atlantic Quality Design, Inc., a consulting firm located in Fincastle, Virginia. He has experience in many areas of embedded software and hardware development, and system design. See www.aqdi.com for more information.