1. c語言編程米ing明明代碼檢查了是對的，為什麼編譯器說是錯的
看看你用的一些符號是不是中文狀態下輸入的，比如分號，雙引號什麼的
2. gcc編譯器在編譯過程會進行哪些檢查
一個編譯器，執行的時候
先會做詞法分析，其中會判斷是否符合詞法規范，一般用有限自動機寫
然後是語法分析，自頂向下的LL和自底向上的LR，會判斷是否符合文法規范
然後就是四元式，語義動作、匯編指令，後面的檢查應該就不多了
3. C++編譯器每個具體的地方如何使用，希望幫助下
找相關書籍資料看吧，這么問太空洞了，不知如何說起。
4. 編譯器本身是如何進行測試的
編譯器最重要的性質就是保證語義的正確。比如，從高級語言翻譯到機器指令之後，指令必須正確的表達原來程序的意思。所以一般編譯器測試都包含一些源程序，用來覆蓋可能出現的各種情況。基本的原則是：原來程序的結果 = 編譯後機器指令運行的結果。機器指令運行的結果很容易知道，運行一下就知道了。可是原來程序的結果你怎麼知道呢？
為了解決這個「原來程序語義」的問題，最好是寫一個解釋器，准確無誤的表達原來的代碼的語義。所以我們的要求就是：
高級語言解釋器（源程序） = 機器執行（機器代碼）
由於處理器其實就是一個用來執行機器代碼的解釋器，這里有一個很美好的對稱關系：
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 的正確性了。
這些是基本的語義測試原理。另外除了語義，可能還有一些「表面」一些的測試，它們看代碼本身，而不只看它的語義。比如尾遞歸優化的測試應該確保輸出程序的尾遞歸得到正確的處理，等等。這些是語義測試檢查不到的，因為尾遞歸沒有正確處理的程序大部分也能輸出正確的結果。
普通的單元測試方法也可以用來測試一些編譯器里的輔助函數，但那些不是編譯器特有的，所以就不講了。
另外，就像所有測試的局限性一樣，你沒法枚舉所有可能出現的輸入，所以以上的測試方法其實也不能保證編譯器的完全正確。
5. 在Java編譯器中用什麼樣的機制來實現數組邊界檢查
int[] i = {1,2,3,4,5,6,7,8,9};
for(j=0;i.length>j;j++){....}
length就是了
6. 為什麼guess number程序編譯器檢查時，總在srand行報錯求大神看
srand( (unsgined) time( NULL ) ); 拼寫錯，應是 unsigned
也可略去 unsigned
7. 簡單c++問題，幫幫小弟。
C++編譯器是不對數組邊界進行檢查的，但是有個問題：比如
int i,a[10];
for(i=0;i<=10;i++)
{
a[i]=0;
}
上面的語句就可能是一個無限循環。因為當i=10的時候a[10]的值被賦值為0，而a[10]又不在定義的數組內，根據遞減內存分配方式，a[10]被分配給i了，故這個是個無限循環。一般是不會報錯的，但是也有編譯報錯的可能。
8. C#的數組邊界檢查的底層原理是什麼
c#的數組是一個對象，而不是一段單純的棧內存空間。數組對象里包含了length屬性嘍！
類似於C語言的結構體：
struct Array{
datatype data[SIZE];
int length;
}
9. C 語言中編譯器為何不檢測數組下標越界問題
以前還真沒想過，記得老師講的時候也沒說，就是強調這是C語言的歷史問題，從一開始就沒有，後來這個功能也沒有加上。至於具體的原因已知模稜兩可，今天總算查清楚了。 綜合網上的各種資料，可以得到如下的結果： 1. 在一個固定的機器之下，指針所佔的位數都是一樣的，換言之，保存的地址是有最大值的，這樣如果每次都檢查數組的越界問題，會對指針的功能做出很大的限制，因為指針只是包含地址信息並沒有包含長度的信息，比如一個 char ch[100]; char * test=ch; 之後test也可以只想超過100的長度的字元串類型，並不是局限與100。如果檢測長度，那麼就相當與限制的指針的長度，這是不合理的。 2. 沒有效率，需要付出代價。具體：最早的C編譯器並不檢查下標，而最新的編譯器依然不對它進行檢查。這項任務之所以很困難，是因為下標引用可以作為任意的指針，而不僅僅是數組名。作用於指針的下標引用的有效性既依賴於該指針當時恰好指向什麼內容，也依賴於下標的值。結果，C的下標檢查所涉及的開銷比你開始想像的要多。編譯器必須在程序中插入指令，證實下標的結果所引用的元素和指針表達式所指向的元素屬於同一個數組。這個比較操作需要程序中所有數組的位置和長度方面的信息，這將佔用一些空間。當程序運行時，這些信息必須進行更新，以反映自動和動態分配的數組，這又將佔用一定的時間。因此，即使是那些提供了下標檢查的編譯器通常也會提供一些開關，允許你去掉下標檢查。
10. 最近在做一個利用VC6.0+opencv1.0環境，做canny邊緣檢測，但是編譯器老是報錯，不能編譯cxcore.hpp,求指點
參考http://www.opencv.org.cn/index.php/VC6%E4%B8%8B%E5%AE%89%E8%A3%85%E4%B8%8E%E9%85%8D%E7%BD%AEOpenCV1.0