C++对象模型解析：深入理解与应用

需积分: 9 184 浏览量更新于2024-07-24 收藏 1.12MB PDF 举报

"《Inside the C++ Object Model》是由Stanley B. Lippman编著的一本关于C++对象模型的书籍，英文完整版，包含了书签目录和封面，无‘trial version’字样，旨在提供一个高质量的阅读版本。本书详细探讨了C++中支持面向对象编程的底层机制，如构造函数的语义、临时对象的生成、封装的支持、继承以及虚函数和虚继承等核心概念。" 《Inside the C++ Object Model》深入探讨了C++对象模型中隐含的程序行为，帮助读者更高效且自信地编写代码。作者Stanley B. Lippman澄清了一些关于C++的误解和关于其开销和复杂性的谣言，同时也指出了可能存在成本和权衡的领域，这些有时是隐藏的。他详细介绍了各种实现模型的由来，预测了它们可能的发展方向，并解释了为什么它们会成为现在这样。这本书的主要亮点包括： 1. 探索C++对象模型在支持面向对象编程时的内在行为。这涉及到如何通过类和对象来实现抽象和封装，以及如何利用构造函数和析构函数来管理对象的生命周期。 2. 解释了基本的内存管理和对象布局。C++中的对象是如何在内存中存储的，以及如何通过指针和引用来访问和操作它们。 3. 讨论了临时对象的生成和销毁过程，这是理解C++表达式求值顺序和短路逻辑的关键。 4. 深入剖析了C++的继承机制，包括单一继承和多重继承，以及它们对类层次结构的影响。 5. 虚函数和虚继承是C++多态性的重要组成部分，Lippman详细阐述了它们的工作原理，包括虚函数表和动态绑定的概念，以及这些特性如何影响性能和代码设计。 6. 阐述了C++对象模型对程序性能的影响，包括静态类型检查、运行时类型信息（RTTI）和异常处理的开销。 7. 书中还可能涵盖了模板、STL（标准模板库）以及C++标准的发展，这些都是现代C++编程中的关键元素。通过学习《Inside the C++ Object Model》，开发者可以更好地理解C++的底层工作原理，从而编写出更优化、更健壮的代码，同时对C++语言的潜力和限制有更深的认识。对于任何想要提升C++技能的程序员来说，这是一本不可或缺的参考书。

Although this model is not used in practice, this simple concept of an index or slot number is

the one that has been developed into the C++ pointer-to-member concept (see [LIPP88]).

A Table-driven Object Model

For an implementation to maintain a uniform representation for the objects of all classes, an

alternative object model might factor out all member specific information, placing it in a data

member and member function pair of tables. The class object contains the pointers to the

two member tables. The member function table is a sequence of slots, with each slot

addressing a member. The data member table directly holds the data. This is shown in

Figure 1.2 (on page 8).

Figure 1.2. Member Table Object Model

Although this model is not used in practice within C++, the concept of a member function

table has been the traditional implementation supporting efficient runtime resolution of

virtual functions.

[1]

At least one implementation of the CORBA ORB has used a form of this two table model. The SOM

object model also relies on this two table model [HAM95].

The C++ Object Model

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:

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

virtual table).

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.

Figure 1.3 illustrates the general C++ Object Model for our Point class. The primary strength

of the C++ Object Model is its space and runtime efficiency. Its primary drawback is the

need to recompile unmodified code that makes use of an object of a class for which there

has been an addition, removal, or modification of the nonstatic class data members. (The

two table model, for example, offers more flexibility by providing an additional level of

indirection. But it does this at the cost of space and runtime efficiency.)

Figure 1.3. C++ Object Model

Page 15

Adding Inheritance

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.

In both schemes, the degree of indirection increases with the depth of the inheritance

chain; for example, a Rental_book requires two indirections to access an inherited member

of its Library_materials class, whereas Book requires only one. A uniform access time could

be gained by duplicating within the derived class a pointer to each base class within the

inheritance chain. The tradeoff is in the additional space required to maintain the additional

pointers.

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

Page 16

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.

The introduction of virtual base classes into the language at the time of Release 2.0

required some form of indirect base class representation. The original model of virtual base

class support added a pointer into the class object for each associated virtual base class.

Alternative models have evolved that either introduce a virtual base class table or augment

the existing virtual table to maintain the location of each virtual base class (see Section 3.4

for a discussion).

How the Object Model Effects Programs

In practice, what does this mean for the programmer? Support for the object model results

in both modifications of the existing program code and the insertion of additional code. For

example, given the following function, where class X defines a copy constructor, virtual

destructor, and virtual function

foo()

X foobar()

{

X xx;

X *px = new X;

// foo() is virtual function

xx.foo();

px->foo();

delete px;

return xx;

};

the likely internal transformation of the function looks as follows:

// Probable internal transformation

// Pseudo C++ code

void foobar( X &_result )

{

// construct _result

// _result replaces local xx ...

_result.X::X();

// expand X *px = new X;

px = _new( sizeof( X ));

if ( px != 0 )

px->X::X();

// expand xx.foo(): suppress virtual mechanism

// replace xx with _result

foo( &_result );

// expand px->foo() using virtual mechanism

( *px->_vtbl[ 2 ] )( px )

// expand delete px;

if ( px != 0 ) {

( *px->_vtbl[ 1 ] )( px ); // destructor

_delete( px );

}

// replace named return statement

// no need to destroy local object xx

return;

};

Wow, that really is different, isn't it? Of course, you're not supposed to understand all

these transformations at this point in the book. In the subsequent chapters, I look at the

Page 17

Book: Inside the C++ Object Model

Section: Chapter 1.?Object Lessons

1.2 A Keyword Distinction

Because C++ strives to maintain (as close as possible) language compatibility with C, C++

is considerably more complicated than it would otherwise be. For example, overloaded

function resolution would be a lot simpler if there were not eight flavors of integer to

support. Similarly, if C++ were to throw off the C declaration syntax, lookahead would not

be required to determine that the following is an invocation of

rather than its definition:

// don't know if declaration or invocation

// until see the integer constant 1024

int ( *pf )( 1024 );

On the following declaration, lookahead does not even work:

// meta-language rule:

// declaration of pq, not invocation

int ( *pq )( );

A meta-language rule is required, dictating that when the language cannot distinguish

between a declaration and an expression, it is to be interpreted as a declaration.

Similarly, the concept of a class could be supported by a single class keyword, if C++ were

not required to support existing C code and, with that, the keyword struct. Surprisingly,

one of the most-asked questions of C programmers moving to C++ (once the questions

about performance have been put aside) is when, if ever, should one use a struct declaration

rather than a class declaration when writing a program using C++?

In 1986, my answer to this question was an unequivocal "never." In both the first and

second editions of my C++ Primer, the keyword struct does not appear in the text, except

in Appendix C, which, logically enough, discusses the C language. At that time, this was one

of those small philosophical points that one necessarily does not point out. However, it is

one from which one gains some small (admittedly quite small) satisfaction when, well, when

it is pointed out, usually as a question: "Hey, did you know? Struct. The keyword. It's not

used anywhere.? But as a colleague of mine at Bell Laboratories indirectly pointed out to

me, even the smallest philosophical point can have a human cost. For example, a C

programmer in his group, anxious to learn C++, was quite distressed to find struct absent

from my book. Apparently its inclusion would have provided a transitional lifeline to make

the programmer's rocky ascent less bruising. So much, then, for philosophy.

Keywords, Schmeewords

One answer to the question of when, if ever, you should use a struct declaration rather

than a class declaration then, is whenever it makes one feel better.

Although this answer does not achieve a high technical level, it does point out an important

distinction that it is important not to make: the keyword struct by itself does not necessarily

signify anything about the declaration to follow. We can use struct in place of class, but still

declare public, protected, and private sections and a full public interface, as well as specify

virtual functions and the full range of single, multiple, and virtual inheritance. Back in the

"early days," it seemed everyone would spend a full 10 minutes of a one-hour introductory

talk on C++ distinguishing the nondistinction between

class cplus_plus_keyword {

public:

// mumble ...

};

and its C equivalent

struct c_keyword {

// the same mumble

};

When people and textbooks speak of a struct, they mean a data aggregate without private

Page 19

剩余190页未读，继续阅读

melochale

粉丝: 3
资源: 10

C++对象模型解析：深入理解与应用

Inside the C++ object Model

Inside C++ Object Model

深度探索C++对象模型（中文版&英文版）

C++对象模型深度解析：Inside the C++ Object Model

C++物件模型探索：深度解析Inside the C++ Object Model

inside the c++ object model 英文原版 高清扫描

inside the c++ object model

最新资源

inside the c++ object model 英文原版高清扫描