編譯器效果

『壹』 C語言同一段代碼，同樣的文件，編譯器為什麼運行結果不一樣

有如下幾種可能：
1 代碼運行的平台硬體不同。
不同的CPU，如嵌入式CPU，intel CPU，以及IBM的CPU，在硬體最底層就是不同的，而C語言是一門和底層相關性極大的語言，在不同的硬體上運行出不同結果是很正常的。

2 代碼運行的系統不同。
相同CPU在不同操作系統上跑相同代碼時，一樣會出現不同的結果。這是由於系統底層的實現不同造成的。比如linux和Windows，在底層處理上就有一定的差異。

3 編譯器不同，同時代碼中使用了C規范未定義規則的語句。
C語言規范並沒有對C語言的所有行為做定義，所以相同語句，不同編譯器的運行效果可能有所不同。比如同樣的sizeof(int)，在16位編譯器上結果為2，而32位編譯器上就會是4。

4 代碼獲取到的外部數據不同。
比如運行代碼時獲取到的其它輸入不同，包括程序中獲取的環境變數，實時信息，以及各種外部輸入等，均有可能出現不同。
比如在做隨機數時，如果以當前時間設定隨機數種子，由於每次的時間是不同的，同一個程序每次運行的結果都是不同的。

『貳』 現代C/C++編譯器有多智能能做出什麼厲害的優化

基本的循環外提，計算削弱，數據流分析合並都已經比較成熟了，可以說不考慮專用cpu優化的情況，其優化效率已經可以和一名中高級編譯專家手工優化的效果差不多。

『叄』 C語言用的編譯器還有分別呢嗎

C語言用的編譯器有分別,不同的平台上的編譯器無疑是不同的，同一種平台上不同公司出的編譯器也不同。

因為編譯器本身也是程序，它們的頭文件內容不同，它們自帶的特殊函數不同，這都影響我們程序的寫法,程序中的調用函數名，函數的參數個數，內容。

即使是同一公司，同一編譯器，例如MS VC++, 版本不同也不同，6.0版的程序在5.0上可能通不過，專業版的在企業版，學生版上編譯通不過，司空見慣啦。

同一編譯器，編譯方法設定不同，（是否優化，動態靜態鏈接等），編出的可執行程序也是不同的。

當然，對一些初級程序來說，用哪個編譯器都沒問題。

C語言可以作圖形界面。例如unix用X-window 庫函數，或調Motif,或GL庫.

PC上的C語言，調用GLUT庫還可以支持3維作圖，不用說2維了。

至於用戶圖形界面--UGI（User Graphic Interface) ,windwos環境下還是用VC++調MFC 為最佳捷徑。

『肆』 arm-none-eabi-gcc對比mdk編譯效率和實際效果怎麼樣

eabi是arm新的二進制文件介面的標准，elf是二進制目標文件的格式，而名稱為arm-elf的編譯器一般是老的OABI介面，裸奔程序到影響不大，在嵌入式linux中，要注意系統的介面，是老的oabi還是eabi，新的內核一般是eabi介面，但編譯內核時會有兼用oab...

『伍』 練習1.1.2：編譯器相對於解釋器的優點是什麼解釋器相對於編譯器的優點是什麼

一個編譯器產生的機器語言目標程序通常比一個解釋器快很多，解釋器的錯誤診斷效果通常比編譯器更好。

『陸』 Clang 比 GCC 編譯器好在哪裡

編譯速度更快、編譯產出更小、出錯提示更友好。尤其是在比較極端的情況下。

兩年多前曾經寫過一個Scheme解釋器，詞法分析和語法解析部分大約2000行，用的是Boost.Spirit——一個重度依賴C++模版元編程的框架。當時攔姿孝用g++ 4.2編譯的情況是：

1.編譯速度極慢：完整編譯一次需要20分鍾

2.編譯過程中內存消耗極大：單個g++實例內存峰值消耗超過1G
3.中間產出物極大：編譯出的所有.o文件加在一起大約1~2G，debug鏈接產物超過200M
4.編譯錯誤極其難以理解：編譯錯誤經常長達幾十K，基本不可讀，最要命的是編譯錯誤經常會長到被g++截斷，看不到真正出錯的位置，基本上只能靠裸看代碼來調試
這里先不論我使用Spirit的方式是不是有問題，或者Spirit框架自身的問題。我當時因為實在忍受不了g++，轉而嘗試clang。當時用的是clang 2.8，剛剛可以完整編譯Boost，效果讓我很滿意：
1.編譯速度有顯著提升，記得大約是g++的1/3或1/4
2.編譯過程中的內存消耗差別好像不大
3.中間產出物及最終鏈接產物，記得也是g++的1/3或1/4
4.相較於g++，編譯錯誤可讀性有所飛躍，至少不會出現編譯錯誤過長被截斷的問題了
當時最大的缺點是clang編譯出的可執行文件無法用gdb調試，需要用調試器的時候還得用g++再編譯一遍。不過這個問題後來解決了，我不知道是clang支持了gdb還是gdb支持了clang。至少我當前在Ubuntu下用clang 3.0編譯出的二進制文件已經可以順利用gdb調試了冊羨。

最後一點，其他同學也有講到，就是Clang採用的簡稿是BSD協議。這是蘋果資助LLVM、FreeBSD淘汰GCC換用Clang的一個重要原因。

『柒』 現代C/C++編譯器有多智能

最近在搞C/C++代碼的性能優化，發現很多時候自以為的優化其實編譯器早就優化過了，得結合反匯編才能看出到底要做什麼樣的優化。
請熟悉編譯器的同學結合操作系統和硬體談一談現代c/c++編譯器到底有多智能吧。哪些書本上的優化方法其實早就過時了？
以及程序員做什麼會讓編譯器能更好的自動優化代碼？
舉個栗子：
1，循環展開，大部分編譯器設置flag後會自動展開；
2，順序SIMD優化，大部分編譯器設置flag後也會自動優化成SIMD指令；
3，減少中間變數，大部分編譯器會自動優化掉中間變數；
etc.
查看代碼對應的匯編：
Compiler Explorer
【以下解答】
舉個之前看過的例子：
int calc_hash(signed char *s){ static const int N = 100003; int ret = 1; while (*s) { ret = ret * 131 + *s; ++ s; } ret %= N; if (ret < 0) ret += N; //注意這句 return ret;}
【以下解答】
舉個簡單例子，一到一百求和
#include int sum() { int ret= 0; int i; for(i = 1; i <= 100; i++) ret+=i; return ret;}int main() { printf("%d\n", sum()); return 0;}
【以下解答】
話題太大，碼字花時間…
先放傳送門好了。
請看Google的C++編譯器組老大Chandler Carruth的演講。這個演講是從編譯器研發工程師的角度出發，以Clang/LLVM編譯C++為例，向一般C++程序員介紹理解編譯器優化的思維模型。它講解了C++編譯器會做的一些常見優化，而不會深入到LLVM具體是如何實現這些優化的，所以即使不懂編譯原理的C++程序員看這個演講也不會有壓力。
Understanding Compiler Optimization - Chandler Carruth - Opening Keynote Meeting C++ 2015
演示稿：https://meetingcpp.com/tl_files/mcpp/2015/talks/meetingcxx_2015-understanding_compiler_optimization_themed_.pdf
錄像：https://www.youtube.com/watch?v=FnGCDLhaxKU（打不開請自備工具…）
Agner Fog寫的優化手冊也永遠是值得參考的文檔。其中的C++優化手冊：
Optimizing software in C++ - An optimization guide for Windows, Linux and Mac platforms - Agner Fog
要稍微深入一點的話，GCC和LLVM的文檔其實都對各自的內部實現有不錯的介紹。
GCC：GNU Compiler Collection (GCC) Internals
LLVM：LLVM』s Analysis and Transform Passes
========================================
反模式（anti-patterns）
1. 為了「優化」而減少源碼中局部變數的個數
這可能是最沒用的手工「優化」了。特別是遇到在高級語言中「不用臨時變數來交換兩個變數」這種場景的時候。
看另一個問題有感：有什麼像a=a+b;b=a-b;a=a-b;這樣的演算法或者知識？ - 編程
2. 為了「優化」而把應該傳值的參數改為傳引用
（待續…）
【以下解答】
推薦讀一讀這里的幾個文檔：
Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
其中第一篇：http://www.agner.org/optimize/optimizing_cpp.pdf
講解了C++不同領域的優化思路和問題，還有編譯器做了哪些優化，以及如何代碼配合編譯器優化。還有優化多線程、使用向量指令等的介紹，推薦看看。
感覺比較符合你的部分需求。
【以下解答】
一份比較老的slides：
http://www.fefe.de/source-code-optimization.pdf
【以下解答】
利用C++11的range-based for loop語法可以實現類似python里的range生成器，也就是實現一個range對象，使得
for(auto i : range(start, stop, step))
【以下解答】
我覺得都不用現代。。。。寄存器分配和指令調度最智能了
【以下解答】
每次編譯poco庫的時候我都覺得很為難GCC
【以下解答】
有些智能並不能保證代碼變換前後語義是等價的
【以下解答】
誒誒，我錯了各位，GCC是可以藉助 SSE 的 xmm 寄存器進行優化的，經 @RednaxelaFX 才知道應該添加 -march=native 選項。我以前不了解 -march 選項，去研究下再來補充為什麼加和不加區別這么大。
十分抱歉黑錯了。。。以後再找別的點來黑。
誤導大家了，實在抱歉。(??ˇ?ˇ??)
/*********以下是並不正確的原答案*********/
我是來黑 GCC的。
最近在搞編譯器相關的活，編譯OpenSSL的時候有一段這樣的代碼：
BN_ULONG a0,a1,a2,a3; // EmmetZC 註：BN_ULONG 其實就是 unsigned longa0=B[0]; a1=B[1]; a2=B[2]; a3=B[3];A[0]=a0; A[1]=a1; A[2]=a2; A[3]=a3;
【以下解答】
提示:找不到對象
【以下解答】
忍不住抖個機靈。
私以為正常寫代碼情況下編譯器就能優化，才叫智能編譯器。要程序員絞盡腦汁去考慮怎麼寫代碼能讓編譯器更好優化，甚至降低了可讀性，那就沒有起到透明屏蔽的作用。
智能編譯器應該是程序猿要較勁腦汁才能讓編譯器不優化。
理論上是這樣的。折疊我吧。
【以下解答】
編譯器智能到每次我都覺得自己很智障。
【以下解答】
雖然題主內容里是想問編譯器代碼性能優化方面的內容，但題目里既然說到編譯器的的智能，我就偏一下方向來說吧。
有什麼更能展示編譯器的強大和智能？
自然是c++的模版元編程
template meta programming
簡單解釋的話就是寫代碼的代碼，寫的還是c++，但能讓編譯器在編譯期間生成正常的c++代碼。
沒接觸過的話，是不是聽上去感覺就是宏替換的加強版？感覺不到它的強大呢？
只是簡單用的話，效果上這樣理解也沒什麼
但是一旦深入下去，尤其翻看大神寫的東西，這明明看著就是c++的代碼，但TM怎麼完全看不懂他在干什麼？後來才知道這其實完全是另外一個世界，可是明明是另外一個世界的東西但它又可以用來做很多正常c++能做的事....
什麼？你說它好像不能做這個，不能做那個，好像做不了太多東西，錯了，大錯特錯。就像你和高手考試都考了100分的故事一樣，雖然分數一樣，但你是努力努力再努力才得了滿分，而高手只是因為卷面分只有100分.....在元編程面前，只有想不到，沒有做不到。
再回頭看看其他答案，編譯器順手幫你求個和，丟棄下無用代碼，就已經被驚呼強大了，那模板元編程這種幾乎能在編譯期直接幫你「生成」包含復雜邏輯的c++代碼，甚至還能間接「執行」一些復雜邏輯，這樣的編譯器是不是算怪獸級的強大？
一個編譯器同時支持編譯語法相似但結果不同卻又關聯的兩種依賴語言，這個編譯器有多強大多智能？
寫的人思維都要轉換幾次，編譯器轉著圈嵌著套翻著番兒地編譯代碼的代碼也肯定是無比蛋疼的，你說它有多強大多智能？
一個代碼創造另外一個代碼，自己能按照相似的規則生成自己，是不是聽上去已經有人工智慧的發展趨勢了？
上帝說，要有光，於是有了光。
老子曰，一生二，二生三，三生萬物。
信c++，得永生！
===
FBI WARNING：模板元編程雖然很強大，但也有不少缺點，尤其對於大型項目，為了你以及身邊同事的身心健康，請務必適度且謹慎的使用。勿亂入坑，回頭是岸。
【以下解答】
c++11的auto自動類型推斷算么....
【以下解答】
智能到開不同級別的優化，程序行為會不同 2333
【以下解答】
這個取決於你的水平

『捌』 css 絕對定位 在瀏覽器和編譯器里效果不同應該怎麼解決

你是指IE9 以下出現的問題嗎 ？
比如.property {_background:red} 其中的「_」 只支持 ie6 網上 有很多 講解這方面的 一找就野銀如有了
如果你說的是 火狐和谷歌的話 也是 可以用以上的 方法
不過個人建議 你在外面寫一個 DIV 做相頌啟對定位 這樣可以減少誤差 實在不搏源行 你就上代碼吧

『玖』 C語言編譯器哪些好

C語言是比較基礎的語言，很多編程軟體都可以接受C的編程的。但C的東西不多，哪個軟體都能完全容納它，所以用哪個軟體都OK的了，主要是看個人喜好和你以後發展方向來選擇的。如果你以後還想學VC++的話或者你要過計算機二級，那現在就下VC6.0 。如果你想做網站的話就下VS2008（或VS2005）。LINUX的GCC 作為一個初學者，應該還不會涉及到的。