編譯器程序大小差別

1. 為什麼編譯生成同樣一個簡單的控制台程序，微軟編譯出來的比GCC的小那麼多

沒這回事。
GCC不能編譯Windows程序，而微軟發布的編譯器也編譯不了Linux程序，它們不可能編譯出同一個程序，最多是編譯出一個程序在這兩個平台上的移植版（就是兩個不同的程序了）。這時候要看程序自身是調用的Windows功能多還是Linux功能多，編譯出來的可執行程序也是可大可小，沒有一定的大小關系。
騰訊QQ的Windows版有幾十兆，而它的Linux版不到5兆……
控制台是微軟VS里的說法，終端是Linux下的說法，這樣的比較，擺明了要耍賴啊。

2. 為什麼我用DevC++編譯的helloworld程序exe文件為16kB，而用visualC++6.0編譯，大小卻高達240kB

很正常，每種編譯器對代碼的處理、優化的演算法都不相同。有的代碼緊湊，有的速度快，等等。另外，有很多編譯器有各種開關設置（或者以宏的方式設置），不同的設置生成的代碼大小也不一樣，比如有的包含了調試所用的信息，自然也會大些。
不過，大小差了這么多，可能有兩種情況（因為我是用別的語言的，你這兩個編譯器我還不是很熟悉，只能猜測）：一是前者是不是DOS下的，後者是不是WINDOWS下的（WINDOWS下運行的程序更復雜）？二是如前所說，後者是不是包含了調試信息？查一下編譯器的開關設置。

3. 相同的程序經51跟PIC編譯器編譯後大小差距那麼大

兩者的構架不同，指令集也不同，同樣功能，PIC的指令數量大概是51的1.5倍，如果有大量的單位元組乘除計算，51的要小的多。
另外就是，HEX不是真實程度的大小，還有，51匯流排8位寬，PIC的一般是12位甚至更多位，兩者比較意義不大

4. 單片機程序大小是看生成的HEX文件的大小還是看KEIL編譯結束後顯示的CODE大小

這里有一點需要的是:
無論是HEX的大小，還是編譯後CODE的大小，都不是燒入到MCU中代碼的「真實」容量。
因為這里涉及到數據存放格式相關問題，具體我就不說了。
一般來說，燒入到MCU硬體中去的程序大小，會比你keil編譯後的CODE的大小稍微小一些，但差距不會很大。
所以在一般使用中，可以把編譯後CODE的大小來作為實際程序容量的一個參考，，，話再說回來，LZ一般不會去那樣極限編程吧，LZ你編譯後，CODE的大小是多少呢？？

我的郵箱是：
[email protected]
有什麼問題的話，可以郵件交流等。

5. 不同編譯器為什麼對數據分配的存儲單元大小不同，分配的大小與程序運行有關嗎

額，不同的編譯器對同一種類型變數分配的存儲單元大小不同。。。不同就不同了。。。沒有為什麼。。。畢竟當初沒有統一的標准。不過都是微小的差別，影響不大。我們不需要知道為什麼不同，只要知道它們分配的確實不同就行了。
分配的大小與程序運行有關的。同樣是一個int型，在VC下被分配4位元組，在TC下被分配2位元組。實際程序運行的時候，也是前者吃掉4位元組的內存，後者吃掉2位元組的內存。

6. G++ 和 C++ 編譯器編譯出的程序 運行後內存使用不同 這是為什麼

內存分配，不同的編譯器採用不同的方法，其速度，效率，內存大小都不一樣。你搜一下malloc的演算法。有一個大致的了解。
關於頭文件的問題，不同的編譯器，對標準的實現有所不同，可以理解的。

7. 在VB中是不是代碼越少，所編譯出來的exe文件體積越小

有些控制項大小不定，代碼可能很少，體積卻很大。大小主要看除了代碼的控制項和其他內容，控制項一半以上和程序大小有關系，不妨想一想么，給你舉個例子。
把一個30K的控制項叫做A控制項，假如代碼一行就是20個字元，一個字元為1K，下面兩個程序的其它內容都是100K：這個程序有10個控制項，代碼共30行；那個程序有30個控制項，代碼共3行。（每個控制項代碼字元數量不同，加起來正好30行、正好3行。）那第一個程序大小是30K控制項內容×10個控制項+30行代碼×20個字元（20K字元內容）+100K其他內容=1000K內容，這個程序有30行代碼的大小，總大小1000K，第二個程序大小是30K控制項內容×30個控制項+5行代碼×20個字元（20K字元內容）+100K其他內容=1000K內容，這個程序共有3行代碼的大小，總大小1000K。
第一個程序代碼多，並不比第二個程序小。

8. 不同的c語言編譯系統差別在哪裡代碼是否 存在兼容性的問題

ANSI
C
一般都可以支持，但也涉及到不同版本的C標準的兼容性問題，比如VC6不支持C99，VS2003,2005,2008,20120等就可以部分支持C99標准；而且很多標准並沒有規定實現，不同的
編譯器
實現可能不同，比如C標准只規定了short<=int<=long,但並沒有規定
位元組
數，導致不同的編譯器
數據類型
的大小各不相同。
非
ANSI
C標準的話，不同的編譯器一般都有不同的實現，需要分別實現。
在移植到不同編譯器的時候這些都要注意處理，比較常規的做法是數據類型和
函數
等自己根據不同編譯器封裝成一個統一的格式，在
程序
中使用封裝後的數據類型或函數，而不要使用原生類型，這樣在移植時只需要在封裝的地方根據編譯器的不同進行修改就可以了，不需要再修改
源代碼
。

9. 我用c++源碼編譯出來的執行程序和官方編譯比大小和運行速度會不一樣嗎官方可能有自己的一套編譯環境嗎

你看看自己是 debug編譯還是release編譯。是32位編譯還是64位編譯唄。
如果你編譯的是debug版本，那麼肯定比較大也比較慢。這個關鍵看你編譯傳入的操作。

當然編譯器的版本也可能有關系，gcc和vc 這種編譯器種類不同也有關系，甚至於編譯的目標平台也有關系。

10. 編譯器版本不一會不會有差別

各種程序設計語言的編譯器版本肯定是會有差別的。但是編譯器版本一般都是向下兼容的。例如：你在舊版本的 C 編譯器中編寫的 C 語言源代碼，若 C 語言編譯器的版本升級到了新版本，它肯定會完全兼容你原來在舊版本中編寫的所有 C 語言源代碼；但是反之是不行的。
因為在新的編譯器版本中，除了增加了一些必須要修改的各種 bug 之外，肯定還會增加一些新的庫函數供用戶使用，使得用戶編程更加方便、得心應手。