• <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| 久久精品亚洲男人的天堂| 久久99久久无码毛片一区二区| 久久国产综合精品五月天| 久久久一本精品99久久精品88| 色婷婷综合久久久久中文| 9191精品国产免费久久| 亚洲一级Av无码毛片久久精品| 日韩av无码久久精品免费| 国产福利电影一区二区三区久久久久成人精品综合 | 欧美久久天天综合香蕉伊| 性高湖久久久久久久久| 久久国产精品免费一区| 精品久久久久中文字幕日本| 亚洲欧洲中文日韩久久AV乱码| 久久精品国产影库免费看| 思思久久精品在热线热| 久久国产视频网| AAA级久久久精品无码区| 久久久久女人精品毛片| 亚洲人成网亚洲欧洲无码久久| 国产精品欧美久久久久无广告| 久久精品无码专区免费青青 | 久久久亚洲AV波多野结衣| 国产精品久久久久久久午夜片| 国产精品九九九久久九九| 无码人妻久久一区二区三区免费丨| 久久精品中文字幕有码| 亚洲一区二区三区日本久久九| 欧洲成人午夜精品无码区久久| 亚洲欧美一级久久精品| 亚洲精品无码久久久久AV麻豆| 久久精品国产精品亜洲毛片| 99久久无码一区人妻| 国产成人精品久久亚洲高清不卡 | 亚洲精品乱码久久久久久自慰| 亚洲国产精品一区二区三区久久 | 亚洲国产精品无码久久| 伊人久久大香线蕉精品不卡| 伊人精品久久久久7777|