Portable Inheritance and Polymorphism in C, 12/97

In spite of theunquestionedadvantages of OOlanguages, C stillremains the bestknown implementationlanguage.best known and widespread implementationlanguage. Many embedded systemstoday still simply do not offer anyother choice. Consequently, mostdevelopers still exclusively use proceduralprogramming techniques, andmany are unaware that it’s quite easyto implement key OO concepts directlyin C. Promoting this awareness maybe important for at least two reasons.The first is leveraging OO technology.Most OO designs can be implementedin C, but many developerswouldn’t consider them without theavailability of an OO language. Thisunnecessarily limits application of thetechnology.The second is smoothing transitionfrom procedural to OO thinking.Migrating to OO technology canrequire quite a leap in your way ofthinking. Implementing OO conceptsin currently used and familiar languagesgives you an opportunity to getexposed to the new programming paradigmright away and without majorinvestment.ENCAPSULATIONYou can achieve packaging ofdata with functions in C bymaking each class attribute(instance variable) a field in the Cstruct. You implement class methodsas C functions that take as their firstargument the pointer to the structure ofattributes (the this pointer). You canfurther strengthen the associationbetween the attributes and methods bya consistent naming convention formethod names. The most popular conventionthat I adopt is to concatenatethe structure name (class name) withthe operation name. This altering offunction names is part of name decorating(also known as name mangling)and is performed implicitly by mostC++ compilers. Because name decoratingeliminates method name clashesbetween different classes, it effectivelypartitions the flat C function namespaceinto separate namespaces nestedwithin classes.The next aspect I address by a codingconvention is access control. In C,you can only indicate your intentionfor the level of access permitted to aparticular attribute or a method.Conveying this intention through thename of an attribute or a method is betterthan just expressing it in the form ofa comment at the declaration point. Inthis way, unintentional access to classmembers in any portion of the codewill be easier to detect. Most OOdesigns distinguish the following threelevels of protection:■■■private—accessible only from withinthe classprotected—accessible only by theclass and its subclassespublic—available anywhere (defaultin C)I use a double underscore prefix(__foo) for private attributes. Note thatthere is usually no need to expose privatemethods (helper methods) in theclass declaration file (.H file). Rather,you should hide them completely inthe implementation file (declare themstatic in the .C file). For protectedmembers I use a single underscore(_foo, String_Foo). I avoid using underscoresin the public members at all(foo, StringFoo). So, with this convention,the presence of underscores in aname is a signal that access rightsshould be checked against the contextof use. Because public members can beused without any constraints, theydon’t need any special adornment.Every class must provide at leastone constructor method for initializationof its attribute structure.Constructor calls should be the onlymethod of initialization. Otherwise, theinternal structure of an object must beDECEMBER 1997 EMBEDDED SYSTEMS PROGRAMMING 55

Portable Inheritance and Polymorphismexposed, thereby compromisingencapsulation.Optionally, a class may provide adestructor, which is a method responsiblefor releasing the resources allocatedduring the lifetime of an object.Whereas there may be many ways ofinstantating a class (different constructorstaking different arguments), thereshould be only one way of destroyingan object.Because of the special role of constructorsand destructors, I againadvise a consistent naming pattern. Iuse base names “Con” (FooCon1,FooCon2) and “Des” (FooDes) for constructorsand destructors, respectively.I suggest that constructors return eitherthe pointer to a properly initializedattribute structure, or NULL if initializationfails. The destructor should takeonly the this argument and shouldreturn void.Objects can be allocated statically,dynamically (on the heap), or automatically(on the stack). Because of C syntaxlimitations, you generally cannotinitialize objects through a constructorcall at the definition point. For staticobjects, you cannot call a constructorat all, because function calls aren’t permittedin a static initializer. Automaticobjects must all be defined at thebeginning of a block and at this point,you will generally not have enough initializationinformation to call an appropriateconstructor. Therefore, you willoften have to divorce object allocationfrom initialization. You should treatobjects as all other C variables, in thatyou never use them before initialization.Typically, you’ll want to initializeobjects as soon as the initializationinformation becomes available.Some objects may require destruction,and calling destructors for allobjects when they become obsolete orgo out of scope is a good programmingpractice. Later, I’ll show that a virtualdestructor is available for all classes.INHERITANCEInheritance is a mechanism bywhich new and more specializedclasses can be defined in terms ofexisting classes. When a child class(subclass) inherits from a parent class(superclass), the subclass then includesthe definitions of all the attributes andmethods that the superclass defines.Usually, the subclass extends thesuperclass by adding its own attributesand methods. Objects that are instancesof the subclass contain all data definedby the subclass and its parent classes,and they are able to perform all operationsdefined by this subclass and itsparents.This kind of class relationship canbe implemented in C by embedding theparent class attribute structure as the56 EMBEDDED SYSTEMS PROGRAMMING DECEMBER 1997

Portable Inheritance and Polymorphismyourself that these modifications don’trequire any manual changes to subclasses.I also strongly recommend thatyou step through the code using adebugger.Encapsulation,inheritance, andpolymorphism arenothing but designpatterns at the Clanguage level.WHAT’S TO LOSE?So what do you lose by using Crather than an OO language?Using the techniques I’ve presentedhere, you don’t have to sacrificemuch convenience and expressiveness,because you can fairly easily map mostimportant OO concepts to C. Youdon’t have to compromise much maintainabilityeither, because you canautomate many tasks. The most importantfeature of this implementation isthat adding new attributes and methods(including virtual functions and interfaces)to the superclass doesn’t requireany manual changes to subclasses.The real issue is that C requires significantlyhigher programming disciplinein object initialization andcleanup than OO languages, especiallythose with garbage collection. But thisis a well known deficiency of C, whichisn’t to be repaired easily. (For example,C++ is still plagued by most ofthese problems.)Encapsulation, inheritance, andpolymorphism are nothing but designpatterns at the C language level(Gamma, 1995). As do all design patterns,they bring a higher (OO) level ofabstraction by introducing their specificnaming conventions and idioms. Ifyou aren’t comfortable with my conventions,you should adopt your own.Most important is consistency, whichdramatically improves code readabilityand allows for quick identification ofthe patterns.If you start using these patterns, youwill probably notice that they completelychange your thinking and programmingstyle in C. You’ll not onlyfind your C code to be more similar toJava, you’ll find yourself more preparedfor Java.Miro Samek is a software engineer atGE Medical Systems, currently developingreal-time, embedded software fordiagnostics x-ray equipment. He holdsa PhD in physics from JagiellonianUniversity in Cracow, Poland. Mirohas previously worked on nuclearphysics experiments at GSI Darmstadt,Germany. He may be reached atmiroslaw.samek@med.ge.com.REFERENCES1. Gosling, James and HenryMcGilton, “The Java LanguageEnvironment: A White Paper,” SunMicrosystems, 1995.2. Rumbaugh, James, MichaelBlaha, William Premerlani, FrederickEddy, and William Loernsen. Object-Oriented Modelling and Design.Englewood Cliffs, NJ: Prentice Hall,1991.3. Eckel, Bruce. Thinking in C++.Englewood Cliffs, NJ: Prentice Hall,1995.4. Gamma, Erich, Richard Helm,Ralph Johnson, and John Vlissides.Design Patterns: Elements of ReusableObject-Oriented Software. Reading,MA: Addison-Wesley, 1995.5. Arnold, Ken and James Gosling.The Java Programming Language.Reading, MA: Addison-Wesley, 1996.66 EMBEDDED SYSTEMS PROGRAMMING DECEMBER 1997