Object Lessons From Lippman, C++ Object Model / PDF

Object Lessons From Lippman, C++ Object Model / PDF

Introduction

In C, a data abstraction and the operations that perform on it are declared separately—that is, there is no language-supported relationship between data and functions. We speak of this method of programming as procedural, driven by a set of algorithms divided into task-oriented functions operating on shared, external data. For example, if we declare a struct Point3d, such as the following:

typedef struct point3d 

{ 

   float x; 

   float y; 

   float z; 

} Point3d; 

the operation to print a particular Point3d might be defined either as a function

void 

Point3d_print( const Point3d *pd ) 

{ 

   printf(”( %g, %g, %g )”, pd->x, pd->y, pd->z ); 

} 

or, for efficiency, as a preprocessor macro:

#define Point3d_print( pd )  \ 

   printf(”( %g, %g, %g )”, pd->x, pd->y, pd->z ); 

Or it may be directly implemented within individual code segments:

void 

my_foo() 

{ 

   Point3d *pd = get_a_point(); 

   ... 

   /* print the point directly ... */ 

   printf(”( %g, %g, %g )”, pd->x, pd->y, pd->z ); 

} 

Similarly, a particular coordinate member of a point is accessed either directly:

Point3d pt; 

pt.x = 0.0; 

or through a preprocessor macro:

#define X( p, xval ) (p.x) = (xval); 

... 

X( pt, 0.0 ); 

In C++, Point3d is likely to be implemented either as an independent abstract data type (ADT):

class Point3d 

{ 

public: 

   Point3d( float x = 0.0, 

            float y = 0.0, float z = 0.0 ) 

      : _x( x ), _y( y ), _z( z ) {} 

   float x() { return _x; } 

   float y() { return _y; } 

   float z() { return _z; } 

   void x( float xval ) { _x = xval; } 

   // ... etc ... 

private: 

   float _x; 

   float _y; 

   float _z; 

}; 

inline ostream& 

operator<<( ostream &os, const Point3d &pt ) 

{ 

   os << ”( ” << pt.x() << ”, ” 

      << pt.y() << ”, ” << pt.z() << ” )”; 

}; 

or as a two- or three-level class hierarchy:

class Point { 

public: 

   Point( float x = 0.0 ) : _x( x ) {} 

   float x() { return _x; } 

   void x( float xval ) { _x = xval; } 

   // ... 

protected: 

   float _x; 

}; 

class Point2d : public Point { 

public: 

   Point2d( float x = 0.0, float y = 0.0 ) 

      : Point( x ), _y( y ) {} 

   float y() { return _y; } 

   void y( float yval ) { _y = yval; } 

   // ... 

protected: 

   float _y; 

}; 

class Point3d : public Point2d { 

public: 

   Point3d( float x = 0.0, float y = 0.0, float z = 0.0 ) 

      : Point2d( x, y ), _z( z ) {} 

   float z() { return _z; } 

   void z( float zval ) { _z = zval; } 

   // ... 

protected: 

   float _z; 

}; 

Moreover, either of these implementations may be parameterized, either by the type of the coordinate:

template < class type > 

class Point3d 

{ 

public: 

   Point3d( type x = 0.0, 

            type y = 0.0, type z = 0.0 ) 

      : _x( x ), _y( y ), _z( z ) {} 

   type x() { return _x; } 

   void x( type xval ) { _x = xval; } 

   // ... etc ... 

private: 

   type _x; 

   type _y; 

   type _z; 

}; 

or by both the type and number of coordinates:

template < class type, int dim > 

class Point 

{ 

public: 

   Point(); 

   Point( type coords[ dim ] ) { 

      for ( int index = 0; index < dim; index++ ) 

         _coords[ index ] = coords[ index ]; 

   } 

   type& operator[]( int index ) { 

      assert( index < dim && index >= 0 ); 

      return _coords[ index ]; } 

   type  operator[]( int index ) const 

      { /* same as non-const instance */ } 

   // ... etc ... 

private: 

   type _coords[ dim ]; 

}; 

inline 

template < class type, int dim > 

ostream& 

operator<<( ostream &os, const Point< type, dim > &pt ) 

{ 

   os << ”( ”; 

   for ( int ix = 0; ix < dim-1; ix++ ) 

      os << pt[ ix ] << ”, ” 

   os << pt[ dim–1]; 

   os << ” )”; 

} 

These are obviously not only very different styles of programming, but also very different ways of thinking about our programs. There are many more or less convincing arguments for why the data encapsulation of an ADT or class hierarchy is better (in the software engineering sense) than the procedural use of global data such as that in C programs. Those arguments, however, are often lost on programmers who are charged with getting an application up and running quickly and efficiently. The appeal of C is both its leanness and its relative simplicity.

The C++ implementations of a 3D point are more complicated than their C counterpart, particularly the template instances. This doesn’t mean they are not also considerably more powerful or, again in a software engineering sense, better. But being more powerful or better is not necessarily a convincing argument for their use.

Section : Layout Costs for Adding Encapsulation

An obvious first question a programmer might ask while looking at the transformed Point3d implementations under C++ concerns the layout costs for adding encapsulation. The answer is that there are no additional layout costs for supporting the class Point3d. The three coordinate data members are directly contained within each class object, as they are in the C struct. The member functions, although included in the class declaration, are not reflected in the object layout; one copy only of each non-inline member function is generated. Each inline function has either zero or one definition of itself generated within each module in which it is used. The Point3d class has no space or runtime penalty in supporting encapsulation. As you will see, the primary layout and access-time overheads within C++ are associated with the virtuals, that is,

• the virtual function mechanism in its support of an efficient run-time binding, and
• a virtual base class in its support of a single, shared instance of a base class occurring multiple times within an inheritance hierarchy.

There is also additional overhead under multiple inheritance in the conversion between a derived class and its second or subsequent base class. In general, however, there is no inherent reason a program in C++ need be any larger or slower than its equivalent C program.

Section 1.1: The C++ Object Model

In C++, there are two flavors of class data members—static and nonstatic—and three flavors of class member functions—static, nonstatic, and virtual. Given the following declaration of a class Point:

class Point 

{ 

public: 

   Point( float xval ); 

   virtual ~Point(); 

   float x() const; 

   static int PointCount(); 

protected: 

   virtual ostream& 

      print( ostream &os ) const; 

   float _x; 

   static int _point_count; 

}; 

how is the class Point to be represented within the machine? That is, how do we model the various flavors of data and function members?

Section : A Simple Object Model

Our first object model is admittedly very simple. It might be used for a C++ implementation designed to minimize the complexity of the compiler at the expense of space and runtime efficiency. In this simple model, an object is a sequence of slots, where each slot points to a member. The members are assigned a slot in the order of their declarations. There is a slot for each data or function member........ 

Object Lessons From Lippman, C++ Object Model / PDF