asm, c, c++ are my all
-- Core In Computer
posts - 139,  comments - 123,  trackbacks - 0

|    欢迎转载, 但请保留作者姓名和原文链接, 祝您进步并共勉!     |

C++对象模型(11) - 3.3 Access of a Data Member
作者: Jerry Cat
时间: 2006/11/15

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).但其可视范围只在类内.

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,

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::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::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

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(减一用以让编译系统区分两类数据成员指针: 一种是寻址第一个数据成员; 另一种是不对数据成员寻址). Pointers to data members are discussed in more detail in Section 3.6.)

编译时确定, 效率不减.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; //当面临虚基类时&pt->x是不确定的, 而&origin.x则是在编译时确定的
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.

posted on 2006-11-15 23:37 Jerry Cat 阅读(1028) 评论(0)  编辑 收藏 引用

【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理