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

Consider the structures:

struct s1
{  int x;
   int y;
};
struct s2
{  int x;
   int y;
   int z;
};

struct s1 *s1p;
struct s2 s2s;
s1p = &s2s;

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

• 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

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);

An Example Application

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.

Conclusion

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.

Acknowledgements