Linux 下進行 C/C++ 開發一般使用什麼開發環境？

01-14

為什麼沒人用clang+llvm，這才是神器，比gcc友好了數十倍，特別是出錯提示。

舉個例子，我把一個變數file錯寫成了fil，gcc是這樣提示：

main.c: In function 『main』:

main.c:56: error: 『fil』 undeclared (first use in this function)

main.c:56: error: (Each undeclared identifier is reported only once

main.c:56: error: for each function it appears in.)

clang是這樣提示：

main.c:56:22: error: use of undeclared identifier "fil"; did you mean "file"?

freopen("file","a",fil);

^~~

file

main.c:13:9: note: "file" declared here

FILE* file;

2 diagnostics generated.

這可是在shell中顯示的效果，哪種更好，自己判斷吧。

至於llvm的優化能力等等，請參考：

http://linuxtoy.org/archives/llvm-and-clang.html

http://llvm.org/

我這全是 Linux 環境開發，我就大致介紹以下我們這裡的現狀吧：

編輯器：

vim 用戶：45%

eclipse 用戶：30%

kscope/kate/kdevelop 用戶：15%

emacs 用戶：5%

win虛擬機+source insight用戶：5%

說明一下：

三個k字頭的其實內核都是 kate 的內核，emacs的用戶一般是超牛人。vim 用戶是主流用戶。
source insight 的致命缺點在於不支持 utf-8，而我們會規定所有項目的源代碼使用 utf-8 編碼。顯然，大多數人認同使用 utf-8 是個好習慣，因而 si 的用戶必然被限制無法在代碼中使用和閱讀中文。
其實大多數編輯器不存在明顯的功能殘缺（除了不支持utf-8的source insight），但是很多功能你是需要有團體互相交流才懂的，明確的說 SI 的幾乎所有功能都可以在 vim/eclipse 中實現，對於 vim/eclipse，絕大多數需求在我們這裡可以通過互相交流而弄懂，所以自然滾雪球一樣越來越多。

編譯環境：

統一配發的工具鏈，編譯時使用 chroot 環境。關於這一點沒什麼可說的，編譯環境必然需要所有人全部統一，無論你使用什麼發行版。

版本控制：

有很多項目，通常使用 svn/hg/git。原先使用 svn 的為主，後來都轉到了 hg，目前大多數項目使用 hg。至於 git 因為使用配置太過複雜，目前只有一個項目組使用。對於存在 svn 歷史積澱的項目組來說，hg 確實是一個遠超越 git 的神器。

調試：

從 Linus 大神開始，printf 就一直是調試利器，上面雖然沒有一個人提到 printf 是調試利器，但沒人敢不承認它。——關於這一點在現實中會存在許多變種，例如可以定製自己的宏實現分標誌，分級別，重定向到 syslog，或者文件，遠程 udp socket，等等。相關的工具打造好了之後，你獲取信息會很精準而方便。我個人經常使用 udp socket 來接受日誌輸出。

簡單補充一個，如果需要語義補全、實時編譯檢查這樣的IDE拳頭功能的話，可以試試看基於libclang的一系列工具，比如vim下我很喜歡的YouCompleteMe，還有一些開源IDE也在集成libclang了（kdevelop？）。比起ctags這樣的靜態字元串分析來說，還是強大很多的。

llvm + clang的確很厲害。

我說qt creator會不會被打。。

如果你在公司做開發的話，一般Compilation和Linking這兩步你都是沒得選的，全公司統一的工具。

而你用Linux開發了，大多數情況下都是伺服器，一般來講你都是沒許可權安這個安那個的，XWindow沒有那就是沒有，所以vim和emacs你至少要學會一樣，一般會有Eclipse，但什麼gedit，sublime就別想了。而事實上，如果你習慣linux命令行的很多功能，那你是會習慣vim和less的。另外，grep才是真正幫你理解別人程序的利器。Vim真正的缺點是那個聲音，比如你走到行的盡頭那個九十年代的報錯聲...

GDB是個很nb的東西，但前提是你真的要很明白你在做什麼。因為GDP這東西他沒有很好的GUI，你用step，他能一路走的巨深無比在無數庫里徘徊，最後你根本回不來了就，用next或設breakPoint的話，你其實已經很明白程序的flow了，而到了這個時候，其實printf就夠了。GDB一般是直接找崩潰的地方以及stack trace時很有用。不能說就真比printf更有用。

最後吐個槽，常看馬刺球的人真的太難在非刻意的情況下說對gdb這個名字了... 基本一張口全是gdp...

當年我看 kernel src 經常用 UltraEdit FTP 看。如今出 Linux 版了，就是很貴。

使用Qt不錯，一次編寫多平台編譯，集成開發環境Qt Creator非常好用，Ubuntu 11.10開始內置支持Qt開發環境

沒人用codeblocks嘛。。挺好使的嘛。。

Projects Type: Cloud Store, Cloud Service, C++/Python Middleware Application Servers

Windows side: Notepad++ SecureCRT

Linux side: gcc/g++ vim gdb GNUMake

That is ALL.

編輯：vim
構建：基於scons構造了一套整合thrift、gcc、cpplint的編譯環境
自動構建：Jenkins（hudson）
調試：線上google-breakpad，線下gdb。

開源chromium里的logging模塊
valgrind
版本控制：svn、git
單測：googletest

emacs 編輯器

gcc/g++ 編譯器

gdb 調試工具

valgrind 內存泄露檢查

doxygen 文檔組織工具

vim，但是上手不是很快，其中有個很好用個插件Vimc變成很方便，推薦vim教程：http://globalinheart.wordpress.com/2011/09/07/%E7%AE%80%E6%98%8E-vim-%E7%BB%83%E7%BA%A7%E6%94%BB%E7%95%A5/

sublime text……以及qt 什麼的……

上面的答案比較全了，但我想再補上一個版本管理軟體——git，還有忽然想起的CppUnit測試框架

我想說，我一直都是sublime來編輯，用gdb來調試

上面都回答得差不多了，在補充一個內存調試器：valgrind。

內存出錯，就算一個很有經驗的程序員都很難避免，找起錯誤來還真的不容易。valgrind可以很快的定位程序中的內存錯誤，是一款不錯的軟體。

valgrind可以幫助你定位程序中：

1）哪裡申請的內存，但是沒有釋放

2）哪裡訪問了非法內存。

3）哪裡使用的未初始化內存。

4）動態內存使用統計

5）。。。

扣腚的話我推薦用KATE 很好用的一個軟體比神馬VIM 還記命令什麼的強多了！

KSCOPE也是一個不錯的扣腚工具當然主要還是個讀代碼工具不過面對一個很大的項目用其來扣腚也是很爽的

對了 KSCOPE 1.6.2 之後的1.9版本就不要用了那時候因為KDE的後續發展 API神碼的問題讓作者不爽所以搞出了1.9 遠不如1.6.2好用然後好像作者自己也放棄了這個偉大的項目

不過好在1.6.2用起來感覺不錯所以現在就用KSCOPE 1.6.2吧

anjuta

glade

netbeans

如果vim/emacs消耗了你太多時間，試試kdevelop吧：