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

            C++ library系列 -- STL實現中的ODR “one-definition-rule” for types

            Linking issue
            - While different modules (.obj) using istreambuf_iterator/ostreambuf_iterator, compiled with different options on HID/no-HID and SCL/no-SCL, these modules could not be linked successfully;

            The error comes directly from the CLR when a type has multiple definitions that are not consistent based upon the ODR, one-definition-rule for types. And, the linker itself isn't involved.

            For example, with one module compile with /D_SECURE_SCL=0, while another is compiled with _SECURE_SCL=1;

            At first, it's found that with _SECURE_SCL, the only thing that could be different as following,

            #if _SECURE_SCL
                typedef _Range_checked_iterator_tag _Checked_iterator_category;
            #endif

            But, actually, it's not the typedef that changed the layout the these iterators (istreambuf_iterator/ostreambuf_iterator), and further they don't really use the extra pointer that _SECURE_SCL adds.

            Finally, it's found the root cause is that, these iterators, istreambuf_iterator/ostreambuf_iterator  had been moved from <xutility> to <streambuf>, and their ultimate base class had been changed from _Iterator_base_secure to _Iterator_base. And, the layout of _Iterator_base would be different between HID and no-HID, and between SCL and no-SCL. It is the cause where the issue comes from.

            What we can learn from such issue,
            These iterators really shouldn't derive from either _Iterator_base_secure or _Iterator_base, because these classes contain data members (pointers) which are entirely unused. It would result in unnecessary bloat and extra work being performed in ctor/dtor etc.

            Introduce a new class, _Iterator_base_universal, which is defined identically regardless of HID/no-HID and SCL/no-SCL. It would contains the three internal typedefs that all standard iterators need to have, and nothing else. And _Iterator_base (in all of its variants) and _Iterator_base_secure now should derive from _Iterator_base_universal to get these typedefs.

            Now, when an iterator wants these typedefs, but not the data members of _Iterator_base and _Iterator_base_secure, it could derive from _Iterator_base_universal. And istreambuf_iterator and ostreambuf_iterator are now as small as possible, and keep identical representations or layout across HID/no-HID, SCL/no-SCL.

            posted on 2010-12-19 11:09 flagman 閱讀(1900) 評論(0)  編輯 收藏 引用 所屬分類: C++

            <2025年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            導航

            統計

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久久久香蕉视频| 久久国产精品99精品国产987| 亚洲国产日韩综合久久精品| 亚洲国产成人精品91久久久 | 久久国产免费观看精品3| 久久成人国产精品| 狠狠色丁香婷综合久久| 久久青草国产精品一区| 国产精品久久久久久久久久影院| 18禁黄久久久AAA片| 伊人久久精品无码av一区| 一本色道久久88加勒比—综合| 无码人妻少妇久久中文字幕| 97久久婷婷五月综合色d啪蜜芽| 久久99国产综合精品免费| 日本久久久久久久久久| 亚洲国产精品高清久久久| 精品久久久久久久久久中文字幕| 无码国内精品久久人妻| 99久久婷婷国产综合精品草原| 久久这里只有精品视频99| 亚洲国产成人久久综合碰碰动漫3d| 国产激情久久久久影院小草| 久久久久久久97| 欧美与黑人午夜性猛交久久久| 欧美噜噜久久久XXX| 日韩精品无码久久久久久| 99久久综合国产精品二区| 久久久久亚洲AV无码专区首JN | 国内精品久久久久| 久久久久久国产精品无码下载| 亚洲国产成人久久综合一| 久久精品国产亚洲AV电影| 狠狠色丁香久久婷婷综合蜜芽五月 | 无遮挡粉嫩小泬久久久久久久| 久久人人爽人人爽人人片AV东京热| 亚洲伊人久久大香线蕉综合图片| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 久久综合九色欧美综合狠狠| 色综合久久精品中文字幕首页| 亚洲αv久久久噜噜噜噜噜|