Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Object-Oriented Programming In C

July 1990/Object-Oriented Programming In C

David Brumbaugh is a software developer at Advanced Information Services, Inc. in Peoria IL. He has a B.A. in computer information science from Judson College in Elgin, IL. He has been programming in C since 1985. He can be contacted at Computer Express BBS, (309) 688-9789, 1220-2400 Baud, 8,1,N in the C Language Questions folder.

C programmers have been using something like object oriented programming for years. They called it good modularity.

The classic example of "object-oriented C" is the standard FILE structure and its family of functions fopen, fclose, fread, fwrite, fprintf, etc. Only the "methods" of the file object, fopen etc., access the members of FILE.

The FILE functions are examples of good, modular, manageable code. A more accurate term for this type of programming is "structure driven". Structure-driven programs consist of data structures and functions that support them. The difference may only be semantic, but FILE objects don't have any allowance for inheritance or polymorphism. Structure members and functions that operate on them are not encapsulated into a single object.

Adding More OOPness

This article describes a technique which adds inheritance, polymorphism, and encapsulation to the familiar structure-driven style. The steps of this technique (listed in Table 1) are chosen to work with a particular implementation of inheritance.

Consider the structures:

struct s1
{  int x;
   int y;
struct s2
{  int x;
   int y;
   int z;
Suppose there is a structure of type s2 and a pointer to type s1.

struct s1 *s1p;
struct s2 s2s;
s1p = &s2s;
In almost all C compilers, s1p->x would be the same as s2s.x, and s1p->y would be the same as s2s.y. You could say that structure s2 inherited x and y from structure s1. Any function that expected a pointer to s1 could instead take a pointer to s2 and could correctly address x and y and safely ignore z.

Listing 1 illustrates how to utilize this technique in an easy, self-documenting way. By using #define to define a class, S1, and using this definition to describe a subclass, S2, we assure that any changes to the S1_CLASS definition are automatically reflected in its subclass S2_CLASS at compile time.

An object is an instance of a class. In Listing 1, C's typedef permits objects to be declared.

Coding Conventions

I observe certain conventions when writing methods for this OOP technique.

  • The first argument to a method is always a pointer to the object calling the method. Many C++ translators do the same thing.
  • The first argument to a method is always named this, clarifying references to the calling object.
  • All program code for a particular class is always in the same .c file. Methods are given exactly the same function name as the pointers to those methods. These functions are static, so they don't interfere with other functions of the same name in other files.
  • When writing an abstract base class's methods, write functions for methods that are defined to be subclass implemented. You may simply print a message to the effect that the method is not available.
  • All constructors are named in the form new_CLASS(). The only arguments in constructors are for initialization. The template in Listing 2 is the basis for all constructors. If the constructor is a base class, remove all SUPER_CLASS references from this template.
  • Destructors have a format that reverses the inheritance process. Destructor names have the form destroy_CLASS(). The first, and usually only, argument is a pointer to the object being destroyed. The second template in Listing 2 is the general form of a destructor.

Prior Art

Eric White described another technique for writing "truly" object-oriented programs in the February issue of The C Users Journal. There are some differences between the technique I am suggesting and his.

This technique does not require any data structures other than those required by the objects. There is no specific CLASS structure and no specific OBJECT structure like in White's technique.

This technique does not require the use of any additional functions such as White's message function.

Classes and subclasses are defined using C's #deine directive. Methods are inherited from superclasses in a subclass's constructor, like White's, but no function is required to register new methods.

There are no separate constructors and destructors for CLASS and OBJECT. Constructors and destructors have more responsibility for inheritance and polymorphism.

Scope is used to supply a rudimentary form of polymorphism, an issue not directly addressed by White.

The resulting syntax of this technique is closer to C+ + than White's. Compare the following three object-oriented methods of having a circle draw itself. The first example is C++, the second uses White's technique, and the third uses the technique described here.

   1. circle.draw(radius);
   2. message(&circle,DRAW,radius);
   3. circle->draw(circle,radius);
This similarity to C++ was important to me. Most of the OOP code I have seen in articles has been in C++, and I did not want to have to make a large mental jump to get from C+ + to code I could use.

An Example Application

Many applications need to deal with lists. Sometimes these lists are arrays, sometimes they are linked lists, some- times they are views of database records. This example will develop a LIST_CLASS. The goal is to create a class that will allow an application to have uniform access to all types of lists, without the programmer having to concern himself with how the list is stored.

I developed this object when I needed a selector window. The selector window is used as a menu and chooses a record from a data table. The SELECTOR object had a LIST pointer as a member. Concrete sub-classes of ARRAY_LIST_CLASS and PINNACLE_LIST_CLASS were both used by the SELECTOR, fulfilling the 00 requirement that a subclass can be used in place of a superclass.

I chose the Pinnacle library for two reasons. First, it is a good, modular, "structure-driven" library. I was able to add an OO layer to it by encapsulation. The second reason is availability. Pinnacle is a commercial product, but a free trial disk is available from Vermont Database Corporation. The trial diskette will suffice if you want to try these programs yourself.

In Listing 3 list.h, defines an abstract base class that more concrete classes can inherit from. It defines the types of things you would normally do with a list.

The list will be ordered in some way, even if it is only a physical order. The list will have a "top" and an "end". There will be the concept of a "current" member. The methods in Table 2 are common to all lists.

Some methods, such as seek and total_members, can be written by utilizing other methods. Examine list.c in Listing 3. seek may not contain the most efficient algorithm for all list types, so it can polymorphed later if necessary. The same can be said of total_members.

From this abstract LIST_CLASS, more concrete classes need to be made. The concrete classes must address two issues. First, how the list is implemented. Second, what goes into the list.

What goes into the list is determined by the application. This example will be a simple phone list with a first name, last name and phone number for each entry. The list will be maintained in a last name, first name order. A PHONE_ENTRY structure will be used to hold the data.

How to implement the list is a design decision. For the phone list, a database of some sort may be a logical choice. If the list is temporary, a dynamic array or linked list may be more practical. This is where the OO advantage comes in. If a decision is made to change from a linked list to a database, the changes are made within the class, not to the application.

I have chosen to use two list handling methods to illustrate this technique. The first example uses a dynamic array to hold the elements of the list. The second example uses the Pinnacle relational DBMS to hold the elements.

In Listing 4, arrylist.h and arrylist.c show how a dynamic array can be used to implement the LIST_CLASS. Two new attributes are added to the LIST_CLASS. The curr attribute is the index of the current member, and tot_members is the number of members in the array. The default methods for total_members and seek were not efficient so these methods are polymorphed.

In Listing 5 phlist1.h adds a PHONE_ENTRY pointer to hold the list and a sort method to maintain the list in a sorted order. In phlist.c all methods not previously written are completed.

pinlist.h and pinlist.c in Listing 6 show how a database package can be used to make LIST_CLASS more concrete. Pinnacle is built around the relational model, so a list is defined to be from one table in a database. Column use is application dependent and will be specified in the more concrete subclass.

phlist2.h in Listing 7 defines which columns from the table will be used. A working buffer is also added for convenience. In phlist2.c the constructor defines which table and database to use. I used the sample database provided with Pinnacle.

Listing 8, testlist.c, is the same for both implementations. The output generated by this program is also identical in both cases.

I used Turbo C 2.0 to test the code for this article. To keep some prototyping I turned off the ANSI warning "Suspicious pointer conversion." I could then assign any type of pointer to any other type of pointer and still keep some prototyping. To use this technique on a different compiler, you may have to remove the prototypes entirely.


The technique presented here is not intended to replace object-oriented languages such as C++. Instead, the technique is intended to allow a programmer to experiment with object-oriented techniques without having to invest in learning a new language.

There are a number of advantages to using this technique to write programs. It allows you to realize most of the benefits associated with OOP. Code and data are changed in an organized way through inheritance. Data encapsulation makes the internals of the objects transparent. Maintenance and enhancement are easier because of this encapsulation.

There are some advantages to using this technique over C++ or some other OOL. There are enough differences between C++ and C to make many existing libraries useless. I have seen examples of library functions having names that are C++ reserved words. I have had C++ translators change the names of the functions I call and cause link errors with outside libraries. With this technique, I can use an object-oriented style and still have full access to all the C functions currently in use. This is a significant advantage if one considers the thousands of dollars and man-hours invested in existing libraries.

Changing to any OOP technique carries some disadvantages. There is more overhead when using a derived class because all the code from its superclasses needs to be linked into the program, even when overridden. Bugs are inherited with features. If a superclass contains a design bug, or an inherited technique contains a bug, the whole class hierarchy is affected, complicating the debugging of large class hierarchies.

There are some disadvantages to using this technique over C++. Some prototyping may be sacrificed in inheritance, especially if you change the prototype from one class level to the next. C++ constructors are more automatic.

Finally, this technique isn't strictly portable because it assumes that identical members within different structures are arranged uniformly. Officially, the arrangement of members within a structure is implementation dependent. However, the arrangement assumed here is the rule, rather than the exception, and I have successfully tested the technique with two MS-DOS compilers and one UNIX compiler.


I would like to thank Bob Pauwels and Mike Yocum of Advanced Information Services for their input to this article.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.