gcc哪個編譯速度快

⑴ 綜合來說，幾大主流C++編譯器(icc,gcc,clang,vc++等)究竟孰優孰劣

我曾編出各種C++ 11編譯器的支持，並有C++ 14編譯器支持一批。

實際使用

對VC編譯的速度不斷提高，內存佔用已經從VC12開始明顯提高，而最明顯的是可變參數模板。還有內置的代碼靜態分析，在實際中很有用。32位保護模式下，ss寄存器存的是一個段選擇子，選擇子是一個數字，通過IDT(局部描述符表)或者GDT(全局描述符表)選擇一個段描述符，描述符裡面的信息包含該段的取值范圍和大小。

vc14的靜態分析不在每次載入一個ie（對，以前每分析一個.cpp，就載入一次ie！），速度快了相當多。

⑵ Gcc和llvm編譯器有什麼區別，我這配置哪個快

LLVM與GCC在三段式架構上並沒有本質區別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler Collection，也是Libraries Collection。舉個例子，假如說我要寫一個XYZ語言的優化器，我自己實現了PassXYZ演算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優化器提供的PassA和PassB演算法則提供了XYZ語言與其它語言共性的優化演算法。那麼我可以選擇XYZ優化器在鏈接的時候把LLVM提供的演算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。

⑶ Clang 比 GCC 編譯器好在哪裡

1：Clang編譯速度更快、編譯產出更小、出錯提示更友好。
2：clang還內置有靜態分析工具，可以對代碼進行靜態分析（clang --analyze）。這是gcc做不到的。
3：clang結構更簡單。因為clang只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由llvm完成。所以和全部由自己包下的gcc比起來，clang可以更專注地做好一件事。
4：Clang 的另一個優勢是代碼結構清晰，可以作為庫使用，成為其它 app（主要是 IDE）的內嵌 C/C++ parser。這樣，editor 工具可以使用和 compiler 一樣的 parser 來完成 edit-time 的語法檢查。GCC 的結構比較混亂。業界一直有說法是 FSF 故意如此，以便讓 GCC 無法作為其它 app 的內嵌部分。
5：Clang採用的是BSD協議。這是蘋果資助LLVM、FreeBSD淘汰GCC換用Clang的一個重要原因。

⑷ 哪個軟體的gcc比較好用

編譯器:GCC Clang LLVM
編輯器：VC6.0 DEV VisualStudio Eclipse Notepad VScode 記事本……
GCC原名GNU C語言編譯器
現在大多數編輯器里帶的編譯器都是用的GCC版的。

⑸ Clang 比 GCC 好在哪裡

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

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

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

⑹ Clang 比 GCC 好在哪裡

從代碼上說，clang結構更簡單。因為clang只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由llvm完成。所以和全部由自己包下的gcc比起來，clang可以更專注地做好一件事。

這種結構也使clang可以被單獨拿出來用在其他的程序里。比如vim的clang_complete插件就是利用clang進行語法分析後給出精確的自動補全和語法錯誤提示的。而gcc就沒法很方便地做到這一點。

在實用性方面，除了有更快的編譯速度更快和更友好的出錯提示外，clang還內置有靜態分析工具，可以對代碼進行靜態分析（clang --analyze）。這也是gcc做不到的。

總結如下：

Clang是LLVM的前端，可以用來編譯C，C++，ObjectiveC等語言。傳統的編譯器通常分為三個部分，前端(frontEnd)，優化器(Optimizer)和後端(backEnd)。

在編譯過程中，前端主要負責詞法和語法分析，將源代碼轉化為抽象語法樹；優化器則是在前端的基礎上，對得到的中間代碼進行優化，使代碼更加高效；後端則是將已經優化的中間代碼轉化為針對各自平台的機器代碼。Clang則是以LLVM為後端的一款高效易用，並且與IDE結合很好的編譯前端。

⑺ GCC/G++，ICC，Clang，MSVC，BCC等C/C++編譯器有什麼特長和不足

clang編譯速度快，但是貌似編譯結果運行相對會慢。功能更新一般也比較快。
g++編譯速度比clang慢，編譯結果運行貌似比clang快。功能更新稍慢。
vc這幾年沒編譯過大工程，感覺上編譯速度在clang和g++之間。以過去的經驗g++和vc編譯結果運行速度差不多。功能更新上就是一坨屎。但是在Windows上寫點正經東西你可能不得不用它，相對的你也只能在Windows上用它。
icc很久沒用過，過去印象編譯速度很慢，運行速度最快但是感覺有點得不償失。最大的問題是這東西要錢，前三個都是免費的。
bcc直接無視就好了。

⑻ 求助，gcc的編譯過程太慢

RH，SUSE系列可以用rpm包安裝
Debian系列可以apt安裝
沒用過多個版本gcc並存，不過gcc4重寫了前端，應該加快速度的！

⑼ 目前最好用的c++編譯器是什麼

編譯器：GCC
如果你是要一個能夠編譯c++的軟體，那我推薦code::blocks
dev-c++調試有bug

⑽ Intel C++ Compiler與gcc對比有什麼優缺點

icc 是Intel公司專門為Wintel平台設計，有針對性的做了優化，缺陷也很顯然，既然有針對性，也就不具備通用性。使用icc編譯，可能會使編譯出來的程序有更好的執行效率，但也可能使其在非Intel CPU上運行異常。並且，在某些情況下，即使在Wintel平台上也會崩潰。
gcc的優勢在於其通用性，目前主流的所有平台，它基本上都支持。使用-O3優化編譯後的執行效率，也不錯。
在Win平台上，編譯後執行效率最好的，依然是微軟的vs，這可能與win系統是他們家出的有關。
使用icc帶來的優勢，並不突出，還是建議不要用了。
如果限定在win平台上開發，使用vc或gcc更合適一些。我個人推薦gcc，vc的ide環境過於龐大，不太喜歡，但win平台上主流的c開發工具還是vc，有不少開源的工程都使用它，如果你用到了這些開源代碼，就不得不用了。