不同的編譯環境（vc，
bc，turbo pascal
等等）在處理一些語句的時候存在著很大的不同，這樣就引起了一些相同的語句在不同的編譯環境下有著不同的結果。下面舉例給予說明： 1
、為變數分配的空間不同：對於
int i ,double j.
這兩個語句在
vc6.0
環境下編譯執行的時候，系統為
i,j
分配的空間分別是4，
8個位元組。但是在
tc環境下編譯執行的時候，系統為
i,j
分配的空間分別是2，
4個位元組。如果不熟悉這些編譯系統的不同特性的時候，有時候會出現一些錯誤。例如：在不同的編譯平台編寫的程式之間交換資料的時候，就會因為分配空間的不統一而出現取錯資料的情況。在
vc6.0
有解決這種不匹配的方案。 2
、大家有沒有想過為什麼在
c/c++
語言中，
int a[20]
能夠正確的定義乙個二維陣列，而
int a[20]
卻不是正確的定義呢？這就關係到編譯系統在處理陣列的時候的不同。在
c/c++
語言中，陣列的編址方式是行優先的，在上面的第一種定義方式中，如果你要訪問
a[10][0]
這個元素的時候，你可以根據陣列
a的第乙個元素的位址來得到
a[10][0]
的位址，位址（
a[10][0]）=
位址（a[0][0]
）+10*20*2
。但是對第二種定義方式，你並不能通過
a的第乙個元素的位址獲得
a[10][0]
的位址。因為有這樣的問題發生，所以
c/c++
語言就做出了相應的定義規定。但是對一些陣列的編址方式是列優先的語言來說，第二種方式就是正確性，第一種定義方式卻是錯誤的了。 3
、大家知道，在
c++中，形參的初始化是按從左到右的順序，這主要跟
c++函式的引數壓棧方式有關。
c++的這種特性導致了在使用預設引數的函式的時候必須注意乙個規則：在有預設值的形參右邊，不能出現無預設值的形參。下面舉個例子說明一下：例如
void try(int j, int k=2, int m)
，由於形參的初始化是按左到右的順序，所以如果用
try(1,2)
的方式呼叫函式的時候，程式設計師本意是呼叫
try(1,2,2)
，但是在
vc6.0
環境下進行編譯的時候編譯器卻認為程式設計師是為
j賦值為1，
k賦值為
2，沒有為
m賦值，所以
vc6.0
認為出錯了。為了避免出現這種不必要的錯誤，就定了那麼乙個規則。有些語言中規定了形參的初始化是按從右到左的順序，規則就反過來了。 4
、最後舉乙個例子，請看下面的問題。
int w,z,x,y;
w=5;x=4;
y=w++*w++*w++;
z=--x*--x*--x;
請問一下最後
w,z,x,y
的值為多少呢?
這個問題採用不同的編譯器實現有不同的結果。在
vc6.0
環境下，對於
y=w++*w++*w++
，計算機是這樣做的：先取
w值進行連乘，然後w進行
3次自加，就是
y=5*5*5=125; w=8
。對z=--x*--x*--x
，計算機是這樣做的：首先
x自減兩次，取
x相乘，
x再自減一次，再和上次相乘的結果相乘。因此，
z=2*2*1=4;x=1
。但是在
vc.net
環境和bc3.1
環境下，結果並不是這樣的：對於
y=w++*w++*w++
，計算機是這樣做的：先取
w值進行連乘，然後w進行
3次自加，就是
y=5*5*5=125; w=8;
對z=--x*--x*--x
，計算機是這樣做的：首先
x自減三次，取
x相乘。因此，
z=1*1*1=1;x=1
。為什麼會出現這樣的不同呢？因為對於語言標準沒有定義的語法特性，各種編譯器都出於自己的考慮做了自己的處理（雖然有些處理在我們看來不可理喻的）。
因為編譯器的不同引起相同語句有不同處理的情況還有很多，本文就不打算一一枚舉了。本文的目的是為了引起大家對不同編譯器的處理多做些思考和比較，這些對深入的學習計算機語言有著很大的幫助。
猛龍所帶來的震動
最近真的是完全沉浸入了學習之中，不覺之間發現高中那個對學院派路線不屑一顧的我已經成為了其中乙個典型代表。席間休息的時候猛龍打我 了，恍惚之間一連猜錯了幾次最後才知道是猛龍。猛龍與我先策聊了一下之後便開始很自然地過渡到大學畢業找工作這個話題，先前我以為猛龍只是在談他自己的事，後來猛龍才轉到了關於畢業生...
NRV優化所帶來的困惑
我們知道要了解編譯器在做什麼，nrv優化應該是乙個無法避免的問題，下面來看乙個例子 include iostream 從這兩個程式的執行來看nrv優化好像並不是那麼如你想象中的好 using namespace std include class text private double arry 1...
ToList 所帶來的效能影響
前幾天優化師弟寫的 有乙個地方給我留下很深刻的印象，就是我發現他總是將plinq的結果tolist 然後再返回給主程式，對於這一點我十分不解，於是去問他是什麼原因，得到的答案很幽默 因為習慣。有時候對於方法的不甚了解加上 習慣 往往是程式效能和穩定性終結者，就拿這個case來說吧，原始 如下 var...