後台linux c/c++大型項目開發中在windows下大家一般用什麼工具編輯調試比較順手？

12-29

RT 是最原始的本地編輯再上傳上去調試? 還是直接ssh上去用emacs vim編輯gdb調試? 或還是eclipse netbeans等本地連上去或映射一下？

一般來說，我們會選擇一個在Windows下也可以跑的起來（但可能性能不會優化到極致）的方案，舉例來說，網路程序採用boost.asio/libuv作為底層，UI程序採用Qt作為底層等等。採用cmake或類似方案作為構建系統。

然後在Windows上開發、調試、運行、測試所有邏輯、進行所有單元測試。然後登陸Linux，修復所有因為編譯器差異導致的編譯錯誤（如果你兩邊都採用最新的編譯器，這種差異在通常的代碼里很少見），跑過所有單元測試，然後基本上就是一個可以運行的系統了。

登陸Linux的過程，我選擇XShell+Vi(m)。（很少的）調試選擇原始的printf。對於崩潰性質的問題，採用gdb看調用棧。

既然已經說了是「大型項目」，那麼難免會用到非跨平台的特性。至少實踐中很容易碰到只能在Linux上復現的bug。因此總體的建議還是能在Linux環境下開發調試就盡量在Linux環境下做，以期開發環境和線上運行環境保持一致。

我自己是用Vim，配置比較齊全，可以當低檔C++ IDE用，所以讀寫代碼都用Vim。調試用的是CGDB，提供了一個終端下的簡單的ncurses UI，操作也相當簡單。Windows下要麼putty要麼Cygwin下直接用OpenSSH終端。Cygwin的好處是可以直接在本地起tmux，這樣省去開一坨窗口的麻煩。一般公司都會有一個跳板機，這樣的話在跳板機上起tmux之類也OK。

其他同事基本上都是Windows編輯器中編輯閱讀（Visual Studio、EditPlus、SourceInsight…），然後scp到Linux開發機上編譯調試。也就是說Windows工具主要是為了編輯方便。但很容易引入一些編碼衝突問題：換行符風格混合、UTF-8/GBK衝突（如果不寫中文注釋或中文文檔就還好）、某些Windows編輯器自動加上Unicode BOM導致腳本執行失敗，等等。

總之，混用會有一些坑，如果是單純的Linux項目，不考慮跨平台，最好還是習慣一下直接在Linux下工作。習慣之後省事兒很多。在上家公司是工作需要不得不用Windows，離職後一年半到現在再也沒用過。

我呆過的公司都是跨平台做的，我自己的project也跨平台了。基本上是Windows下開發。Linux上我一般用Code::Blocks，因為是CMake工程。在公司裡面Linux上有問題，就交給懂的人去做就好了。

不過我是覺得，Linux下，還是要以GDB為主的。另外像Valgrind這樣的好使的傢伙一定要多用。

鄙公司作為全平台（windows32/64， linux redhat, linux SUSE, AIX , ios ,mac os ,以前還有solaris, HP的不知道什麼unix）開發的公司可以出來說說

自己組裡主要用VS/vim/emacs/notepad++在windows里寫好，先測試，差不多了，同步到linux下面，跑單元測試。一般代碼上的邏輯問題，linux下面有錯windows下面一樣會出錯。如果是OS dependent 的問題么只好用gdb, idebug, dbx 這種東西硬上，有個insight這種linux 的gdb外殼簡直謝天謝地，小錯直接vim emacs改，大錯最好能在在windows下面重現用VS來分析。

你們在AIX下面debug過一次就會愛上VS了。

JetBrains C++ IDE: Status update Video report

這樣的項目大部分沒有辦法在windows下調試，太多系統介面不存在或者不兼容了

ssh + vim + gdb

SSH+VIM+GDB

利用samba映射到windows下，編輯好後xshell+gdb

說一下我做大型項目的經驗(都是跨平台的.)

Windows:

- VS2008 用來編譯.

- Source Insight 用來查看源碼.

- Notepad++ 用於修改bug,等小改動.

Linux:

- Vim + Gcc

Window 和linux 文件互傳: Xmanager.

如果你不打算用xmanager, 用VNC的方式互傳文件,切記使用壓縮文件再傳,否則跨系統會出問題(文件會自動添加一些系統標示符在末尾端).

分了幾個階段：

剛接觸linux時在win下用source insight寫完，打包後通過手動ftp(你沒看錯)到linux下vim+gdb。

然後試著在win上構建仿linux環境，minGW和cygwin。

後覺缺陷太多不爽，試用同事寫的自動（增量）ftp腳本，仍在本地編輯，伺服器編譯。

後試用RSYNC直接同步文件與命令到伺服器並同步輸出到win，不夠完善。

後仍不爽，試用svn作為媒介同步代碼，略煩。

最後，完全將linux作為工作環境。

說一下我自己的情況吧，我是做Android系統移植的，所以需要使用交叉編譯環境。編輯代碼用Notepad++,閱讀代碼用Source Insight,連接Linux用Putty. 內網開發環境的話還會開啟SAMBA共享，編譯還是在Linux端。整個開發環境涉及日常工作用的Windows系統、編譯用的Linux系統以及跑在ARM開發板上的Android系統。

vim 寫代碼，通過log模塊輸出的日誌調試，或者用printf，遇到崩潰問題就上gdb，core調試堆棧

我認為，原生的最好；

linux程序就老老實實的在linux下開發；

windows程序就老老實實的在windows下開發；

最大的好處是：免麻煩。

Visualgdb啊！

基本應該是列印log 和code 分析了。

crash 就上gdb。

source insight+clear case網路硬碟映射到本地

SSH+VIM+GDB(printf)

ssh+vim, stay away from windows

跨平台為什麼要用c++？用c不是更好

後台linux c/c++大型項目開發中 在windows下 大家一般用什麼工具編輯調試比較順手？

後台linux c/c++大型項目開發中在windows下大家一般用什麼工具編輯調試比較順手？