• <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)

            隨筆檔案

            最新隨筆

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            国产精品亚洲综合久久| 色综合久久综合网观看| 亚洲精品WWW久久久久久| 国产精品成人久久久| 性欧美大战久久久久久久久| 国内精品九九久久久精品| 精品视频久久久久| 久久亚洲国产精品成人AV秋霞| 狠狠精品久久久无码中文字幕| 久久精品国产影库免费看| 欧美一级久久久久久久大片| 久久精品国产网红主播| 久久无码人妻精品一区二区三区| 婷婷综合久久中文字幕蜜桃三电影| 亚洲国产精品热久久| 色欲久久久天天天综合网| 99久久国产主播综合精品| 亚洲色欲久久久综合网东京热| 99久久精品免费观看国产| 亚洲综合日韩久久成人AV| 青青青青久久精品国产h久久精品五福影院1421 | 日韩乱码人妻无码中文字幕久久 | 久久影院亚洲一区| 亚洲嫩草影院久久精品| 精品免费久久久久久久| 久久久久久精品成人免费图片| 久久精品国产只有精品2020| 亚洲精品乱码久久久久久按摩| 人人狠狠综合久久亚洲| 国产成人香蕉久久久久| 亚洲精品高清国产一久久| 久久精品www| 日本久久久久久中文字幕| 狠狠色丁香久久婷婷综合五月| 18岁日韩内射颜射午夜久久成人| 中文字幕精品无码久久久久久3D日动漫| 久久婷婷久久一区二区三区| 国产69精品久久久久777| 久久国产精品国产自线拍免费| 高清免费久久午夜精品| 夜夜亚洲天天久久|