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

C++對(duì)象模型(11) - 3.3 Access of a Data Member
作者: Jerry Cat
時(shí)間: 2006/11/15
鏈接:? http://m.shnenglu.com/jerysun0818/archive/2006/11/15/15193.html

3.3 Access of a Data Member

1. Static Data Members:

Static data members are literally lifted out of their class, as we saw in Section 1.1 and treated as if each were declared as a global variable (but with visibility limited to the scope of the class).但其可視范圍只在類內(nèi).

Each member's access permission and class association is maintained without incurring any space or runtime overhead either in the individual class objects or in the static data member itself.

A single instance of each class static data member is stored within the data segment of the program. Each reference to the static member is internally translated to be a direct reference of that single extern instance. For example,

// origin.chunkSize == 250;
Point3d::chunkSize == 250;

// pt->chunkSize == 250;
Point3d::chunkSize == 250;

What if the access of the static data member is through a function call or some other form of expression? For example, if we write

foobar().chunkSize == 250;

what happens to the invocation of foobar()? In the pre-Standard language, one didn't know what would happen: It was left unspecified in the ARM whether foobar() had to be evaluated. In cfront, for example, it was simply discarded. Standard C++ explicitly requires that foobar() be evaluated, although no use is made of its result. A probable translation looks as follows:

// foobar().chunkSize == 250;

// evaluate expression, discarding result
(void) foobar();
Point3d::chunkSize == 250;
Taking the address of a static data member yields an ordinary pointer of its data type, not a pointer to class member, since the static member is not contained within a class object. For example,

&Point3d::chunkSize;
yields an actual memory address of type
const int*

2. Nonstatic Data Members:

Nonstatic data members are stored directly within each class object and cannot be accessed except through an explicit or implicit class object. An implicit class object is present whenever the programmer directly accesses a nonstatic data member within a member function. For example, in the following code:

Point3d
Point3d::translate( const Point3d &pt ) {
?? x += pt.x;
?? y += pt.y;
?? z += pt.z;
}
the seemingly direct access of x, y, and z is actually carried out through an implicit class object represented by the this pointer. Internally, the function is augmented as follows:

? // internal augmentation of member function
? Point3d
? Point3d::translate( Point3d *const this, const Point3d &pt ) {
???? this->x += pt.x;
???? this->y += pt.y;
???? this->z += pt.z;
? }

Access of a nonstatic data member requires the addition of the beginning address of the class object with the offset location of the data member. For example, given

origin._y = 0.0;
the address of

&origin._y;
is equivalent to the addition of

&origin + ( &Point3d::_y - 1 );//注意減1
(Notice the peculiar "subtract by one" expression applied to the pointer-to-data-member offset value. Offset values yielded by the pointer-to-data-member syntax are always bumped up by one. Doing this permits the compilation system to distinguish between a pointer to data member that is addressing the first member of a class and a pointer to data member that is addressing no member(減一用以讓編譯系統(tǒng)區(qū)分兩類數(shù)據(jù)成員指針: 一種是尋址第一個(gè)數(shù)據(jù)成員; 另一種是不對(duì)數(shù)據(jù)成員尋址). Pointers to data members are discussed in more detail in Section 3.6.)

編譯時(shí)確定, 效率不減.The offset of each nonstatic data member is known at compile time, even if the member belongs to a base class subobject derived through a single or multiple inheritance chain. Access of a nonstatic data member, therefore, is equivalent in performance to that of a C struct member or the member of a nonderived class.

Virtual inheritance introduces an additional level of indirection in the access of its members through a base class subobject. Thus

Point3d *pt3d;
pt3d->_x = 0.0;
performs equivalently if _x is a member of a struct, class, single inheritance hierarchy, or multiple inheritance hierarchy, but it performs somewhat slower if it is a member of a virtual base class. In the next sections, I examine the effect of inheritance on member layout. Before I turn to that, however, recall the question at the beginning of this section: When, if ever, is the access of the coordinate data members, such as

origin.x = 0.0;
pt->x = 0.0; //當(dāng)面臨虛基類時(shí)&pt->x是不確定的, 而&origin.x則是在編譯時(shí)確定的
ever significantly different when accessed through the object origin or the pointer pt? The answer is the access is significantly different when the Point3d class is a derived class containing a virtual base class within its inheritance hierarchy and the member being accessed, such as x, is an inherited member of that virtual base class. In this case, we cannot say with any certainty which class type pt addresses (and therefore we cannot know at compile time the actual offset location of the member), so the resolution of the access must be delayed until runtime through an additional indirection. This is not the case with the object origin. Its type is that of a Point3d class, and the offset location of even inherited virtual base class members are fixed at compile time. An aggressive compiler can therefore resolve the access of x through origin statically.