• <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++對象模型(7) -? Member Initialization List

            作者: Jerry Cat
            時間: 2006/05/12
            鏈接:?
            http://www.shnenglu.com/jerysun0818/archive/2006/05/12/6978.html


            2.4 Member Initialization List
            =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

            When you write a constructor, you have the option of initializing class members either through the
            member initialization list or within the body of the constructor. Except in four cases, which one
            you choose is not significant.

            In this section, I first clarify when use of the initialization list is "significant" and then
            explain what actually gets done with that list internally. I then look at a number of possible,
            subtle pitfalls.

            You must use the member initialization list in the following cases in order for your program to compile:

            (1). When initializing a reference member
            (2). When initializing a const member
            (3). When invoking a base or member class constructor with a set of arguments
            ???? 低效的第四種情況
            In the fourth case, the program compiles and executes correctly. But it does so inefficiently.
            For example, given

            class Word {
            ?? String _name;
            ?? int _cnt;
            public:
            ?? // not wrong, just naive ...
            ?? Word() {
            ????? _name = 0;
            ????? _cnt = 0;
            ?? }
            };
            this implementation of the Word constructor initializes _name once, then overrides the
            initialization with an assignment, resulting in the creation and the destruction of a temporary
            String object. Was this intentional? Unlikely. Does the compiler generate a warning? I'm not aware
            of any that does. Here is the likely internal augmentation of this constructor:
            // Pseudo C++ Code
            Word::Word( /* this pointer goes here */ )
            {
            ?? _name.String::String();???????? // invoke default String constructor
            ?? String temp = String( 0 );????? // generate temporary
            ?? _name.String::operator=( temp );// memberwise copy _name
            ?? temp.String::~String();???????? // destroy temporary
            ?? _cnt = 0;
            }

            Had the code been reviewed by the project and corrected, a significantly more efficient
            implementation would have been coded:
            // preferred implementation
            Word::Word : _name( 0 )
            {
            ?? _cnt = 0;
            }
            This expands to something like this:

            // Pseudo C++ Code
            Word::Word( /* this pointer goes here */ )
            {?? // invoke String( int ) constructor
            ?? _name.String::String( 0 );
            ?? _cnt = 0;
            }
            This pitfall, by the way, is most likely to occur in template code of this form:

            template < class type >
            foo< type >::foo( type t )
            {
            ?? // may or may not be a good idea depending on the actual type of type
            ?? _t = t;
            }
            This has led some programmers to insist rather aggressively that all member initialization be done
            within the member initialization list, even the initialization of a well-behaved member such as _cnt:

            // some insist on this coding style, 順序有問題!
            Word::Word() : _cnt( 0 ), _name( 0 )
            {}

            Actually, there is a subtlety to note here: The order in which the list entries are set down is
            determined by the declaration order of the members within the class declaration, not the order
            within the initialization list. In this case, _name is declared before _cnt in Word and so is placed first.

            This apparent anomaly between initialization order and order within the initialization list can
            lead to the following nasty pitfall:

            class X {
            ?? int i;
            ?? int j;
            public:
            ?? // oops!? do you see the problem?
            ?? X( int val ) : j( val ), i( j )
            ?? {}
            ?? ...
            };

            // preferred idiom, 解決咯
            X::X( int val ) : j( val )
            {
            ?? i = j;
            }

            Here is an interesting question: Are the entries in the initialization list entered such that the
            declaration order of the class is preserved? That is, given

            // An interesting question is asked:
            X::X( int val ) : j( val )
            {
            ?? i = j;
            }
            is the initialization of j inserted before or after the explicit user assignment of j to i? If
            the declaration order is preserved, this code fails badly. The code is correct, however, 這才是
            真正的原因 - because the initialization list entries are placed before explicit user code.
            所以成員初始化不是一股腦兒都放到初始化列表里才是最優方案!

            Another common question is whether you can invoke a member function to initialize a member, such as
            // is the invocation of X::xfoo() ok?? 問得好!
            X::X( int val ) : i( xfoo( val )), j( val )
            {}

            where xfoo() is a member function of X. The answer is yes, but…. To answer the "but" first, I
            reiterate my advice to initialize one member with another inside the constructor body, not in the
            member initialization list. You don't know the dependencies xfoo() has regarding the state of the
            X object to which it is bound. 還是那句話: 別將所有的成員初始化工作全放在構造函數的初始化列表里 -
            By placing xfoo() within the constructor body, you can ensure there is no ambiguity about which
            members are initialized at the point of its invocation.

            The use of the member function is valid (apart from the issue of whether the members it accesses
            have been initialized). This is because the this pointer associated with the object being
            constructed is well formed and the expansion simply takes a form like the following:

            // Pseudo C++ Code: constructor augmentation
            X::X( /* this pointer, */ int val )//一般都將this指針缺省, 但它的確是存在的, 至少對編譯器而言
            {
            ?? i = this->xfoo( val );
            ?? j = val;
            }

            where xfoo() is a member function of X. The answer is yes, but…. To answer the "but" first, I
            reiterate my advice to initialize one member with another inside the constructor body, not in the
            member initialization list. You don't know the dependencies xfoo() has regarding the state of the
            X object to which it is bound. By placing xfoo() within the constructor body, you can ensure
            there is no ambiguity about which members are initialized at the point of its invocation.

            The use of the member function is valid (apart from the issue of whether the members it accesses
            have been initialized). This is because the this pointer associated with the object being
            constructed is well formed and the expansion simply takes a form like the following:
            // Pseudo C++ Code: constructor augmentation
            X::X( /* this pointer, */ int val )
            {
            ?? i = this->xfoo( val );
            ?? j = val;
            }

            In summary, the compiler iterates over and possibly reorders the initialization list to reflect
            the declaration order of the members. It inserts the code within the body of the constructor
            prior to any explicit user code. 成員初始化列表的內容"插"在構造函數的最前端.

            posted on 2006-05-12 00:49 Jerry Cat 閱讀(789) 評論(0)  編輯 收藏 引用

            <2006年10月>
            24252627282930
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            常用鏈接

            留言簿(7)

            隨筆檔案

            最新隨筆

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲精品WWW久久久久久| 久久香综合精品久久伊人| 青青草原综合久久| 欧美与黑人午夜性猛交久久久| 中文成人无码精品久久久不卡| 久久久婷婷五月亚洲97号色| 久久99精品国产麻豆蜜芽| 久久久SS麻豆欧美国产日韩| 一本伊大人香蕉久久网手机| 99精品久久精品一区二区| 亚洲国产精品久久| 久久精品无码午夜福利理论片| 久久综合精品国产一区二区三区| 精品久久久久久久无码| 亚洲国产成人久久综合区| 久久狠狠色狠狠色综合| 日日躁夜夜躁狠狠久久AV| 很黄很污的网站久久mimi色| 国产三级久久久精品麻豆三级| 久久综合狠狠综合久久97色| 91性高湖久久久久| 国产精品无码久久综合| 人人狠狠综合久久88成人| 亚洲v国产v天堂a无码久久| 一本伊大人香蕉久久网手机| 久久久久久午夜成人影院| 久久只这里是精品66| 青青青青久久精品国产h久久精品五福影院1421 | 欧美一区二区精品久久| 久久亚洲日韩精品一区二区三区| 热综合一本伊人久久精品| 久久国产精品免费| 国产亚州精品女人久久久久久 | 伊人久久精品影院| 亚洲日韩欧美一区久久久久我| 99精品伊人久久久大香线蕉| 久久ZYZ资源站无码中文动漫| 久久99精品久久久大学生| 伊人色综合久久天天人手人婷 | 久久婷婷成人综合色综合| 国产精品无码久久久久久|