• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            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
            鏈接:?
            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).但其可視范圍只在類內.

            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(減一用以讓編譯系統區分兩類數據成員指針: 一種是尋址第一個數據成員; 另一種是不對數據成員尋址). 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 閱讀(1225) 評論(0)  編輯 收藏 引用

            <2006年11月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            3456789

            常用鏈接

            留言簿(7)

            隨筆檔案

            最新隨筆

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲美日韩Av中文字幕无码久久久妻妇| 国产亚洲美女精品久久久| 青青草原综合久久大伊人导航 | 无码8090精品久久一区| 合区精品久久久中文字幕一区| 一本久久a久久精品综合香蕉| 青青草原精品99久久精品66| 久久久久久久人妻无码中文字幕爆| 99麻豆久久久国产精品免费 | 精品多毛少妇人妻AV免费久久 | 亚洲嫩草影院久久精品| 天堂无码久久综合东京热| 久久婷婷五月综合色奶水99啪| 亚洲国产精品婷婷久久| 亚洲七七久久精品中文国产| 久久99国产综合精品女同| 午夜精品久久久久成人| 久久精品国产亚洲AV电影| 久久人妻少妇嫩草AV蜜桃| 久久久久亚洲av无码专区| 久久亚洲高清综合| 国产成人综合久久综合| 国产精品99久久久精品无码| 麻豆精品久久精品色综合| 97久久国产亚洲精品超碰热| 人妻久久久一区二区三区| Xx性欧美肥妇精品久久久久久 | 久久久久亚洲精品天堂久久久久久| 精品久久人人爽天天玩人人妻| 精品久久久久久无码中文野结衣| 久久亚洲AV成人出白浆无码国产| 亚洲va久久久久| 伊人久久大香线蕉无码麻豆| 国产免费久久久久久无码| 四虎国产精品免费久久久 | 久久本道久久综合伊人| 久久精品九九亚洲精品天堂| 久久国产色AV免费看| 久久精品国产亚洲av水果派| 色偷偷偷久久伊人大杳蕉| 日韩av无码久久精品免费|