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

            qiezi的學(xué)習(xí)園地

            AS/C/C++/D/Java/JS/Python/Ruby

              C++博客 :: 首頁(yè) :: 新隨筆 ::  ::  :: 管理 ::
            標(biāo)題:Proposal: Operator overloading without temporaries
            作者:Don Clugston <dac@nospam.com.au>

            正文:
            Background: Operator overloading, in the form it exists in C++ and
            currently in D, inherently results in sub-optimal code, because it
            always results in unnecessary temporary objects being created.

            For example,
            X = A - ((B*C) + D)* E;

            becomes:
            T1 = B * C;
            T2 = T1 + D;
            T3 = T2 * E;
            T4 = A - T3;
            X = T4;
            Four objects were created, whereas only one was strictly required.
            In C++, there are libraries like Blitz++ which use complicated
            expression templates in order to avoid these creating these temporaries,
            and provide performance comparable with FORTRAN. I think D can do much
            better...
            Note that temporaries are avoided when using the opXXXAssign() operators
            like +=.

            ===========
            ?? Proposal
            ===========
            (1) Allow the compiler to assume that b = b + c? can be replaced with b
            += c. (In C++, operator + and operator += are just symbols, the compiler
            doesn't know that there is any relationship between them).
            In the example above, this would allow the compiler to generate:
            T1 = B * C;
            T1 += D;
            T1 *= E;

            and we have eliminated two of the three temporaries.
            (2). Fill in the gaps in the operator overloading table by introducing
            opAddAssign_r, opSubAssign_r, etc.

            Just as A.opSubAssign(B)
            is the operation? A -= B? or equivalently? A = A - B, similarly

            A.opSubAssign_r(B)
            would mean
            A = B - A.
            and would only occur when temporaries are generated in expressions. Like
            -=, it's an operation which can frequently be performed very
            efficiently, but at present the language has no way of expressing it.

            Our original example then becomes:

            T1 = B.opMul(C);
            T1.opAddAssign(D);
            T1.opMulAssign(E);
            T1.opSubAssign_r(A);
            X = T1;
            ... and all the useless temporaries are gone!

            More formally, when the expression tree for an expression is generated:
            With a binary operator XXX, operating on left & right nodes:

            if (the left node is *not* an original leaf node) {
            ??? // the left node is a temporary, does not need to be preserved.
            ??? // we don't care if the right node is a temporary or not
            ??? look for opXXXAssign().
            } else if (the the right node is not an original leaf node) {
            ??? // the right node is a temporary
            ??? look for opXXXAssign_r()
            } else {
            ?? // both left and right nodes are leaf nodes, we have to
            ?? // create a temporary
            ??? look for opXXX(), just as it does now.
            }

            These rules also cope with the situation where temporaries are required:
            eg
            X = (A*B) + (C*D);
            becomes
            T1 = A*B;
            T2 = C*D;
            T1 += T2;
            X = T1;

            If this were implemented, it would permanently eradicate (for D) the
            most significant advantage which Fortran has managed to retain over
            object-oriented languages. And I really don't think it would be
            difficult to implement, or have negative side-effects.

            There are a couple of decisions to be made:
            (I) should the compiler use opAdd() and generate a temporary, if
            opAddAssign_r() doesn't exist, to preserve existing behaviour? I think
            the answer to this is YES.
            (II) should the compiler use opAdd() and generate a temporary, if
            oppAddAssign() doesn't exist, to preserve existing behaviour? Again, I'm
            inclined to answer YES.
            (III) If the code includes +=, and there is an opAdd() but no
            opAddAssign(), should the compiler accept this, and just generate an
            opAdd() followed by an assignment?? This would mean that opAdd() would
            generate the += operation as well as +, while opAddAssign() would be a
            performance enhancement. (It would still be possible to have
            opAddAssign() without opAdd(), to have += but not +, but it would not be
            possible to have + without +=). This would mean that += would be
            *purely* syntactic sugar.

            Decision III would be a little more difficult to implement and is of
            less obvious merit, I only mention it as a possibility.

            Comments?
            posted on 2006-03-28 10:31 qiezi 閱讀(546) 評(píng)論(0)  編輯 收藏 引用 所屬分類(lèi): D
            青青热久久国产久精品 | 亚洲国产精品成人AV无码久久综合影院 | 久久亚洲AV成人无码国产| 久久国产精品无码HDAV| 久久九九久精品国产| 伊人久久大香线蕉综合Av| 中文字幕亚洲综合久久| 亚洲欧美伊人久久综合一区二区 | 日本国产精品久久| 久久久久久国产精品免费无码| 国产成人香蕉久久久久| 色偷偷久久一区二区三区| 欧美精品丝袜久久久中文字幕 | 77777亚洲午夜久久多人| 久久精品亚洲男人的天堂| AAA级久久久精品无码片| 狠狠色丁香婷婷久久综合| 久久精品国产亚洲Aⅴ蜜臀色欲| A狠狠久久蜜臀婷色中文网| 欧美亚洲国产精品久久| 亚洲国产成人久久精品99| 国内精品欧美久久精品| 精品免费久久久久久久| 久久无码人妻一区二区三区| 久久精品国产亚洲AV久| 一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 日韩精品无码久久一区二区三| 91精品免费久久久久久久久| 99久久免费国产精品热| 国产三级久久久精品麻豆三级| 日韩乱码人妻无码中文字幕久久| 亚洲日本久久久午夜精品| 无码任你躁久久久久久| 无码乱码观看精品久久| 国内精品久久国产| 亚洲国产精品久久电影欧美| 中文成人无码精品久久久不卡| 亚洲精品tv久久久久| 伊人久久综合精品无码AV专区| 一本色道久久综合狠狠躁| 久久亚洲AV成人出白浆无码国产|