/********************************************\
|????歡迎轉(zhuǎn)載, 但請保留作者姓名和原文鏈接, 祝您進(jìn)步并共勉!???? |
\********************************************/

C++對象模型(1)

作者: Jerry Cat
時(shí)間: 2006/04/20
鏈接: http://www.shnenglu.com/jerysun0818/archive/2006/04/20/5969.html

Chapter 0 : Preface
=-=-=-=-=-=-=-=-=-=
I must also say that the general pattern of virtual function implementation across all current compilation systems is to use a class-specific virtual table of a fixed size that is constructed prior to program execution.

Chapter 1: Object Lessons
=-=-=-=-=-=-=-=-=-=-=-=-=
1.1 The C++ Object Model
-------------------------
(1). 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;
};

Stroustrup's original (and still prevailing) C++ Object Model is derived from the simple object model by optimizing for space and access time. Nonstatic data members are allocated directly within each class object. Static data members are stored outside the individual class object. Static and nonstatic function members are also hoisted outside the class object. Virtual functions are supported in two steps:

? 1). A table of pointers to virtual functions is generated for each class (this is called the virtual table).

? 2). A single pointer to the associated virtual table is inserted within each class object (traditionally, this has been called the vptr). The setting, resetting, and not setting of the vptr is handled automatically through code generated within each class constructor, destructor, and copy assignment operator (this is discussed in Chapter 5). The type_info object associated with each class in support of runtime type identification (RTTI) is also addressed within the virtual table, usually within the table's first slot.

(2). 加入繼承后
C++ supports both single inheritance:

class Library_materials { ... };
class Book : public Library_materials { ... };
class Rental_book : public Book { ... };
and multiple inheritance:

// original pre-Standard iostream implementation
class iostream:
?? public istream,
?? public ostream { ... };
Moreover, the inheritance may be specified as virtual (that is, shared):

class istream : virtual public ios { ... };
class ostream : virtual public ios { ... };

In the case of virtual inheritance, only a single occurrence of the base class is maintained (called a subobject) regardless of how many times the class is derived from within the inheritance chain. iostream, for example, contains only a single instance of the virtual ios base class.

How might a derived class internally model its base class instance? In a simple base class object model, each base class might be assigned a slot within the derived class object. Each slot holds the address of the base class subobject. The primary drawback to this scheme is the space and access-time overhead of the indirection. A benefit is that the size of the class object is unaffected by changes in the size of its associated base classes.

Alternatively, one can imagine a base table model. Here, a base class table is generated for which each slot contains the address of an associated base class, much as the virtual table holds the address of each virtual function. Each class object contains a bptr initialized to address its base class table. The primary drawback to this strategy, of course, is both the space and access-time overhead of the indirection. One benefit is a uniform representation of inheritance within each class object. Each class object would contain a base table pointer at some fixed location regardless of the size or number of its base classes. A second benefit would be the ability to grow, shrink, or otherwise modify the base class table without changing the size of the class objects themselves.

The original inheritance model supported by C++ forgoes all indirection; the data members of the base class subobject are directly stored within the derived class object. This offers the most compact and most efficient access of the base class members. The drawback, of course, is that any change to the base class members, such as adding, removing, or changing a member's type, requires that all code using objects of the base class or any class derived from it be recompiled.