C++ Class Variables (Static) Versus Instance Variables (Non-Static)

Prof. Norm Matloff
University of California, Davis
Davis, CA 95616
matloff@cs.ucdavis.edu

Object-oriented programming (OOP) is very big today. Popular languages which use OOP include C++, Java, Python, Perl and many more. However, many insructors of beginning programming courses, say using C++, are not well-versed in the philosophy of object-oriented programming (OOP). Since OOP is the whole idea behind using C++ instead of C, this is unfortunate. This Web page is intended to remedy this problem, by discussing the roles of static vs. non-static variables in C++, and relating it to general OOP principles.

The central tenet of OOP is Encapsulation, meaning to group together all data and operations into one package, called a class. This way one can find all the items one needs related to a given aspect of one's program in one package, while not being distracted by unrelated items elsewhere in the program. This makes for clearer programming and better reusability of program code.

It is this notion of Encapsulation that leads directly for the need for having two kinds of class member variables, one static and the other non-static, as we will see.

For example, suppose our program deals with employee data for some firm. OOP principles imply that we should define a a class named, say, Employee, with all the variables and functions dealing with employees encapsulated into that class. Each object of that class would correspond to one worker.

In the class Employee, we would have member variables like EmpName, EmpBirthDate and so on, giving the name, birthdate etc on the particular worker who is described in that object of the class. The key point is that the variable, say, EmpName, has a different value in each object, since each employee has a different name.

In general OOP terminology, we say that a variable like EmpName is an instance variable, meaning that it has a different value in each object of the class.

Now suppose we also have a variable named TotEmps, which is a count of how many workers there are altogether. Making this variable global, or making it local to main(), would violate the OOP principle of Encapsulation. After all, TotEmps pertains to employees and thus it should be grouped in with the employee data, i.e. TotEmps should be in the class Employee.

But this variable would NOT have different values in different objects of the class; there is only one count of the total number of employees. In other words, TotEmps cannot be an instance variable. So, OOP defines another kind of member variable, called a class variable: This kind of member variable has the SAME value across all objects of the class. TotEmps, then, must be made a class variable.

C++ designates class variables by the keyword static, and designates instance variables by the lack of that keyword. Java uses this syntax too.

Similarly member functions (i.e. "methods") of a class can be either class methods or instance methods. An instance method operates on a particular object of the class (recall that the "this" pointer points to that object). A class method is not tied to a particular object in this way (and thus it is illegal to use the "this" pointer from within a class function).

Note that in C++, one must allocate global storage for any class variable, in addition to declaring it within the class definition. This is an irritating abomination, and Java does NOT have such a requirement. It is one more reason why I consider Java to be a much nicer language than C++.

By the way, Java does not have any free-standing functions (or global variables, for that matter). Every function must be part of some class. Functions which might be free-standing in C++ are typically class functions in Java. For example, in Java even math functions like sqrt() are members of the Math class.

A nice example of the MECHANICS of class and instance variables in C++ is available at http://www.cse.cuhk.edu.hk/~csc4510/cxx/tutorial.2/9.htm But remember, you need to know more than just the mechanics; you need to understand the kinds of situations in which you would use one type or the other (class vs. instance).