• <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>
            posts - 16,  comments - 34,  trackbacks - 0

            一、 統一的預處理、編譯、鏈接程序


                    一、1. 有些程序同時具有如下功能:

            1. 預處理C/C++源代碼
            2. 編譯C/C++源代碼
            3. 鏈接C/C++目標代碼

            例如:GCC的gcc、g++,MSVC的cl.exe。


                    一、2. 實際的情況也許更加復雜:

            gcc、g++、cl.exe很有可能只是一個啟動器
            用戶只需要使用它們, 它們內部再根據特定條件, 執行其他程序,比如:

            1. gcc、g++編譯C/C++代碼時, 最終會執行cc1/cc1plus程序。
            該程序可能才是真正的C/C++編譯器。

            2. gcc、g++在鏈接C/C++目標代碼時,最終會執行ld程序。
            該程序可能才是真正的鏈接器。

            3. cl.exe程序自己處理C/C++代碼的預處理與編譯工作。

            4. cl.exe程序鏈接時,將執行link.exe
            該程序可能才是真正的鏈接器。


                    一、3. 我們的關注點

            ——上述復雜的情況我們大多數情況下無須操心:

            1. 我們只需要使用gcc、g++
            即使以后GCC將cc1、cc1plus、ld改為別的名字也不會受影響。

            2. 我們只需要使用cl
            即使以后cl不再擔任編譯工作或者link.exe被改為別的名字,同樣不受影響。


            ——我們需要關心這些統一的程序,是根據何種條件, 決定它們的操作的?

            本文只討論編譯:
            1. 它們默認是通過何種條件, 決定按C語法或按C++語法編譯一個翻譯單元的。
            2. 如何顯式指定按C語法或者按C++語法去編譯一個翻譯單元。



            二、 默認情況

            如果不顯式指定操作, gcc、g++、cl都是按文件后綴名來決定操作的。

                    二、1. 測試文件:
            #ifndef __cplusplus
            /* being treated as C translation unit */
            #error !---  C  ---!
            #else
            // being treated as C++ translation unit
            #error !--- C++ ---!
            #endif

            我們建一個沒有后綴的文件,叫nosuffix, 寫入如上內容。
            而且, 我們也不需要編譯出目標代碼。
            只需要測試__cplusplus宏(見《預定義__cplusplus宏》)是否存在,并且用#error報告即可。

            然后建立一些內容完全一樣的文件:

            #include "nosuffix"


            這些文件共有10個:
            c.c、 cpp.cpp、txt.txt、UC.C、UCPP.CPP、cc.cc、cxx.cxx、inl.inl、c++.c++、cp.cp。
            (UC和UCPP是為了測試大寫后綴名)


                    二、2. 測試方法

            對GCC使用:
            gcc(g++) filename >stdout.txt 2>stderr.txt

            對MSVC使用:
            cl filename >stdout.txt 2>stderr.txt


                    二、3. 測試結果

            gcc、g++、cl對以下后綴名文件的默認操作如下

             

            nosuffix

            .c

            .cpp

            .txt

            .C

            .CPP

            .cc

            .cxx

            .inl

            .c++

            .cp

            gcc

            obj

            C

            C++

            obj

            C++

            C++

            C++

            C++

            obj

            C++

            C++

            g++

            obj

            C++

            C++

            obj

            C++

            C++

            C++

            C++

            obj

            C++

            C++

            cl

            obj

            C

            C++

            obj

            C

            C++

            C++

            C++

            obj

            obj

            obj


            對該表的幾點說明:
            1. 表中的obj表示該條件下, 統一程序將它們認作目標文件, 并打算執行鏈接工作。
            這顯然是錯誤的, 因為他們包含的是文本。

            2. gcc、g++(編譯代碼)的區別
            GCC認為帶有.c、.cpp、.C、.CPP、.cc、.cxx、.c++、.cp(但不限于)后綴的文件是C/C++源文件。
            gcc把帶有.c后綴的文件, 當作C源文件, 把帶有其他后綴名的文件當作C++源文件。
            g++將帶有上述所有后綴的文件,都當作C++源文件。

            3. MSVC與GCC的區別
            MSVC認為帶有.c、.cpp、.C、.CPP、.cc、.cxx后綴的文件是C/C++源文件。
            上述GCC相比, 排除了.c++和.cp

            同時,windows下的文件名是不區分大小寫的, 所以.c同.C,.cpp同.CPP是一樣的。
            與GCC相比, .C不再認為是C++源文件, 而是與.c一樣作為C源文件處理。


                    二、4. 測試小結

            由上表以及說明, 如果我們打算編寫跨平臺的代碼

            1. 不推薦使用的后綴名
            .c++、.cp
            ——因為它們不被MSVC支持
            .C
            ——因為MSVC并不區別對待.c與.C


            2. 可以使用的后綴名
            ——對C源文件
            可以使用.c。

            ——對C++源文件
            可以使用.cpp、.cc、.cxx。

            ——.CPP不推薦
            因為在xnix上 a.CPP與a.cpp是2個文件, 而復制到Windows上就將發生重名。
            如果只使用.cpp就可以避免該情況。


            3. 關于.inl
            有些文件內容確實是C/C++代碼, 但是卻不直接作為翻譯單元,而是被其他翻譯單元包含。
            理論上說,它們取任何名字都沒關系。但是將它們取為.inl會得到一些好處:
                ——  暗示該文件包含C/C++代碼
                ——  一些編輯器會對其按C/C++語法進行高亮。




            三、 顯式指定

            有時候需要覆蓋默認情況,顯式指定我們需要的操作。

                    三、1. GCC “-x

            GCC通過-x選項顯式指定編譯源代碼的語言:
            -x c(或-xc)
                ——  將源代碼作為C源文件。
            -x c++、(或-xc++)
                ——  將源代碼作為C++源文件。

            對于“二”中的測試, 只要將命令行改為:
            gcc(g++) -x c (-xc) filename

            所有文件都將被作為C源文件處理, 并輸出 error !---  C  ---!

            而使用如下命令行:
            gcc(g++) -x c++ (-xc++) filename

            所有文件都將被作為C++源文件處理, 并輸出 error !--- C++ ---!


                    三、2. MSVC “/TC” “/TP”

            MSVC通過/TC(/TP)選項, 顯式指定將輸入作為C(C++)源代碼。

            對“二”中的測試, 命令行:
            cl /TC filename

            對所有文件都將輸出 error !---  C  --- !

             

            命令行:
            cl /TP filename

            對所有文件都將輸出 error !--- C++ ---!






            四、總結

            1. 使用“二、4”中推薦的方式,給源代碼文件命名。
            2. 覆蓋默認情況,使用-x(GCC)或者/TC、/TP(MSVC)
            3. 順帶提一點, gcc、g++用作鏈接時, 也有一些區別。
            鏈接C++(或者C/C++混合)目標代碼, 推薦使用g++。
            因為GCC高版本中, gcc鏈接時默認不會導入C++需要的運行時庫。





            相關鏈接:

            ——源代碼
            http://immature.googlecode.com/svn/trunk/iMmature/sample/compiler_options/language

            ——《預定義__cplusplus宏
            http://www.shnenglu.com/ownwaterloo/archive/2009/04/20/predefined_macro___cplusplus.html




            Creative Commons License
            作品采用知識共享署名-非商業性使用-相同方式共享 2.5 中國大陸許可協議進行許可。

            轉載請注明 :
            文章作者 - OwnWaterloo
            發表時間 - 2009年04月20日
            原文鏈接 - http://www.shnenglu.com/ownwaterloo/archive/2009/04/20/compiler_options_language.html

            posted on 2009-04-20 15:02 OwnWaterloo 閱讀(2698) 評論(0)  編輯 收藏 引用
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(8)

            隨筆檔案(16)

            鏈接

            搜索

            •  

            積分與排名

            • 積分 - 197904
            • 排名 - 133

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            伊人久久综合热线大杳蕉下载| 内射无码专区久久亚洲| 久久精品国产亚洲av麻豆蜜芽| 色狠狠久久综合网| 精品永久久福利一区二区| 青青青伊人色综合久久| 久久久免费观成人影院| 久久99精品国产麻豆宅宅| 久久国产精品99久久久久久老狼| 久久99精品国产麻豆宅宅| 性欧美大战久久久久久久| 久久午夜无码鲁丝片| 久久综合日本熟妇| 久久久久四虎国产精品| 77777亚洲午夜久久多人| 精品国产91久久久久久久a| 久久强奷乱码老熟女网站 | 狠狠精品干练久久久无码中文字幕| 久久午夜免费视频| 99久久精品国产毛片| 久久人人妻人人爽人人爽| 日韩久久久久中文字幕人妻| 嫩草影院久久99| 久久精品人人做人人爽97| 久久综合亚洲色HEZYO社区| 99久久国产亚洲高清观看2024 | 久久综合狠狠综合久久97色| 精品久久久噜噜噜久久久| 久久天天躁狠狠躁夜夜avapp| 久久国产精品波多野结衣AV| 7国产欧美日韩综合天堂中文久久久久 | 伊人久久精品线影院| 久久国产亚洲精品无码| 亚洲精品乱码久久久久66| 精品一二三区久久aaa片| 亚洲午夜精品久久久久久浪潮| 国产成人无码精品久久久免费| 久久香蕉国产线看观看乱码| 久久99国产精一区二区三区| 国产一久久香蕉国产线看观看| 国产一区二区三区久久精品|