判斷編譯器

① 在C/C++程序中，怎樣可以知道編譯器是GCC或G++

如果是gcc在預編譯的時候會有一個名叫__GLIBC__的宏，如果是g++會有一個叫做__GLIBCXX__的宏，如果想知道版本可以用宏
#ifdef __GLIBC__
int main () //gcc
#elif __GLIBCXX__
int main() //g++
另外，gcc和g++都不完全算是純編譯器，兩個只有連接器的區別，編譯的方式是基本一樣的

② 如何判斷編譯器所編譯的文件是C方式還是C++的方式編譯的

沒有辦法區分。C++是兼容C的，所以在C++代碼中出現一兩句C的語句也很正常，比如printf之類。（有時候printf確實比cout好用，但是scanf不如cin是一定的）所以只能根據後綴區分吧。

③ 如何在c語言中用宏來判斷當前編譯器

熱心網友
一.
#define是C語言中提供的宏定義命令，其主要目的是為程序員在編程時提供一定的方便，並能在一定程度上提高程序的運行效率，但學生在學習時往往不能理解該命令的本質，總是在此處產生一些困惑，在編程時誤用該命令，使得程序的運行與預期的目的不一致，或者在讀別人寫的程序時，把運行結果理解錯誤，這對 C語言的學習很不利。
1#define命令剖析
1.1 #define的概念
#define命令是C語言中的一個宏定義命令，它用來將一個標識符定義為一個字元串，該標識符被稱為宏名，被定義的字元串稱為替換文本。
該命令有兩種格式：一種是簡單的宏定義，另一種是帶參數的宏定義。
(1) 簡單的宏定義：
#define <宏名><字元串>
例： #define PI 3.1415926
(2) 帶參數的宏定義
#define <宏名> (<參數表>) <宏體>
例： #define A(x) x
一個標識符被宏定義後，該標識符便是一個宏名。這時，在程序中出現的是宏名，在該程序被編譯前，先將宏名用被定義的字元串替換，這稱為宏替換，替換後才進行編譯，宏替換是簡單的替換。
1.2 宏替換發生的時機
為了能夠真正理解#define的作用，讓我們來了解一下對C語言源程序的處理過程。當我們在一個集成的開發環境如Turbo C中將編寫好的源程序進行編譯時，實際經過了預處理、編譯、匯編和連接幾個過程，見圖1。

④ 程序如何自主區分不同編譯器

一般選取編譯器默認的宏
也可以在makefile裡面指定可讀性更好的宏
比如，區分mingw和gcc，就可以用mingw自帶的WIN32來區分

⑤ 怎樣判斷c語言編譯器好壞

for語句的判斷句是在前的，也就是先進行判斷，結果是真才執行循環體，這是for語句的模式。如果你希望判斷在後的話可以用do-while語句.

⑥ 編譯器如何實現if then else 判斷（yacc之類自動構造，非手工）

上括弧或者定義塊

⑦ 如何在C語言中用宏來判斷當前編譯器

1、_MSC_VER 是微軟C/C++編譯器——cl.exe 編譯代碼時預定義的一個宏。需
要針對cl 編寫代碼時， 可以使用該宏進行條件編譯。
2、_MSC_VER 的值表示cl 的版本。需要針對cl 特定版本編寫代碼時， 也可以使用
該宏進行條件編譯。
3、_MSC_VER 的類型是"int"，具體版本號定義如下：
MS VC++ 9.0 _MSC_VER = 1500
MS VC++ 8.0 _MSC_VER = 1400
MS VC++ 7.1 _MSC_VER = 1310
MS VC++ 7.0 _MSC_VER = 1300
MS VC++ 6.0 _MSC_VER = 1200
MS VC++ 5.0 _MSC_VER = 1100
其中MS VC++ 9.0 就是Visual C++ 2008，MS VC++ 8.0 就是Visual C++2005。
二、介紹預定義宏「__GNUC__」
1、__GNUC__ 是gcc 編譯器編譯代碼時預定義的一個宏。需要針對gcc 編寫代碼時，
可以使用該宏進行條件編譯。
2、__GNUC__ 的值表示gcc 的版本。需要針對gcc 特定版本編寫代碼時，也可以使
用該宏進行條件編譯。
3、__GNUC__ 的類型是「int」
三、預定義宏"__MINGW32__"
1、MinGW編譯器
四、symbian sdk 預定義宏：
symbian 平台，定義"__SYMBIAN32_"
3rd MR 版及之前的那個3rd 版本，定義"__SERIES60_30__"
3rd FP1 版，定義"__SERIES60_31__"
3rd FP2 版，定義"__SERIES60_32__"
另外，還有一個"__SERIES60_3x__"。若不需區分具體是哪一個3rd 版，則用之。

⑧ 如何知道電腦里有哪些編譯器

可以看下環境變數PATH的值，一般安裝的編譯器會在這里設置路徑。

⑨ 關於如何判斷gcc之類的編譯器的編譯結果

我們再使用gcc編譯的時候可以讓他的輸出信息保存到文件當中

gccmain.c-omain&>status.txt

上面的命令就是將gcc編譯的信息保存到status.txt文件中，然後我們再程序中讀取文件，看文件是否有內容，沒有內容就說明沒有報錯和警告，編譯成功。有內容就對每一行內容進行判斷，看是warring還是error，只有warring也代表編譯成功，有error代表編譯失敗，然後把這些報錯信息都列印出來就好了。

下面看一下例子：

⑩ 編譯器本身是如何進行測試的

編譯器最重要的性質就是保證語義的正確。比如，從高級語言翻譯到機器指令之後，指令必須正確的表達原來程序的意思。所以一般編譯器測試都包含一些源程序，用來覆蓋可能出現的各種情況。基本的原則是：原來程序的結果 = 編譯後機器指令運行的結果。機器指令運行的結果很容易知道，運行一下就知道了。可是原來程序的結果你怎麼知道呢？
為了解決這個「原來程序語義」的問題，最好是寫一個解釋器，准確無誤的表達原來的代碼的語義。所以我們的要求就是：
高級語言解釋器（源程序） = 機器執行（機器代碼）
由於處理器其實就是一個用來執行機器代碼的解釋器，這里有一個很美好的對稱關系：
interp1(L1) = interp2(L2)
另外還有一個問題，就是編譯器一般需要經過多個轉化步驟（叫做 pass）才能最後編譯為機器指令。比如，
L2 = pass1(source)
L3 = pass2(L2)
L4 = pass3(L3)
Ln = passN(Ln-1)
machine_code = codegen(Ln)
由於源程序經過了很多步驟猜得到最後的機器指令，如果你使用上面的公式，就會出現以下一些情況：
1. 知道結果錯了，但是卻不知道到底是哪一個 pass 錯了。
2. 結果沒有錯，但是中間卻有 pass 實際上是錯的。但是由於之前的 pass 把輸入程序的一些結構給「優化」掉了，所以錯的那個 pass 其實沒能得到觸發錯誤的那個數據結構。所以測試沒能發現錯誤。如果以後前面的那個 pass 被修改，錯誤就會暴露出來。這是非常難以發現的潛伏的危險。
為了防止這些情況出現，一些編譯器（比如 Chez Scheme 和 Kent Dybvig 的課程編譯器）使用了對每一個 pass 進行測試的做法。具體的方法就是為每一個中間語言都寫一個解釋器，把這語言的語義完全的表示出來。這樣我們就需要檢查一組等式：
L2 = pass1(source)
高級語言編譯器（源程序） = interp2(L2) // 測試 pass1 的正確性
L3 = pass2(L2)
interp2(L2) = interp3(L3) // 測試 pass2 的正確性
這樣一來我們就能獨立的判斷每一個 pass 的正確性了。
這些是基本的語義測試原理。另外除了語義，可能還有一些「表面」一些的測試，它們看代碼本身，而不只看它的語義。比如尾遞歸優化的測試應該確保輸出程序的尾遞歸得到正確的處理，等等。這些是語義測試檢查不到的，因為尾遞歸沒有正確處理的程序大部分也能輸出正確的結果。
普通的單元測試方法也可以用來測試一些編譯器里的輔助函數，但那些不是編譯器特有的，所以就不講了。
另外，就像所有測試的局限性一樣，你沒法枚舉所有可能出現的輸入，所以以上的測試方法其實也不能保證編譯器的完全正確。