1樓：jason丶
4,5000行的C++專案怎麼會需要幾分鐘 - - ，一般來說盡可能使用前置宣告而不是直接包含標頭檔案。也可以試試分布式編譯，從VisualStudio 2015開始，整合了乙個對編譯特別是對C++編譯特別友好的外掛程式lncrediBuild。
2樓：w2014
（笑哭）一般編譯時去吃飯。回來會感嘆，這麼快就編譯完了啊。
預設不是只會重新編譯修改過的檔案生成的目標檔案嘛……
我想讓它每次更新手寫Makefile把Clean操作加進來呢……
你這個顯然不需要啊……
所以為啥還這麼慢啊…
你怕是檔案之間交叉亂依賴？
怕是把某個函式的實現放在了.h裡面然後每個cpp都因為了這個.h，一改這個函式全都重新編譯？
要不然不至於這麼慢吧……
正常的話compile乙個檔案十秒以內，link頂多20多秒應該是可以做到的吧……
曬一下配置。機械盤。devcpp編譯HELLOWORLD 3到5秒不等，開多個chrome視窗之後可能達到接近10s
然而大作業時多檔案編譯最慢時也就是十二三秒那樣………雖然沒有題主的專案那麼大，但是跟單檔案小工程編譯用時差距真心不大啊……
所以…如果真的一直這麼慢…
換電腦吧…
3樓：Kert
提一下乙個小眾的編譯系統，tup。
它的特點是在編譯前期把所有依賴和改動都掃瞄一遍構建DAG決定編譯順序，不用重複檢查依賴項，從而節省時間。
缺點是要用特殊的語法寫配置，可用lua擴充套件。因為小眾，搜得到的可供參考的經驗也少。
烏克蘭同事被整體裁員前在產品中引入了這個東西，我們接手後不太適應，覺得擰巴。全新編譯要比原來的makefile快了40%（官方的資料是和makefile差不多，可能是因為我們原來的makefile寫的比較渣），增量編譯應該優勢更大。
4樓：紅色幼月
編幾分鐘很久嗎？
我們這裡一般是通過工具鏈生成project和solution，生成時自動把每十幾個cpp include到乙個worker cpp中，然後編譯由worker cpp構成的project。
使用Incredibuild編譯，只要5分鐘。編譯散cpp大概要半小時。
另外fastbuild可以了解一下
5樓：原子筆
才4-5000行也能編譯這麼久，不知道用了多少模版呢。。。
跟你說個事兒（估計很多人不知道），gcc 也可以用預編譯標頭檔案。 試下把需要例項化的類在預編譯標頭檔案裡typedef一下，讓預編譯結果包含一波模版例項化（第一階段查詢）結果，不知道會不會對你的問題有幫助。
6樓：
前置申明，減少 include，不過這是降低可維護性的，注意權衡。
標頭檔案中儘量減少模版庫的引用。
使用工具整理，盡量只include 使用的庫預編譯分布式編譯
最後，學會喝咖啡或者別的愛好，編譯的時候有事可做逃）
7樓：陳曉輝
make -j + ccache+distcc，基本可以保證make的時候最大程度增加併發度。前提是makefile依賴寫對。
對於特別大的專案，把output目錄放在tmpfs裡面，windows下放到ramdisk裡。缺點是斷電就沒了，所以及時生成package.
8樓：馮文斌
使用分布式編譯軟體，IncrediBuild。IncredI Build無縫整合到Visual Studio開發環境，通過使用Xoreax分布式編譯(多執行緒處理)技術, Visual Studio project的編譯速度將大大提高
這個軟體很強大，內網裡只要安裝好VS和IncrediBuild的電腦，通過其中一台作為中心伺服器服配置就可以進行分布式編譯了。它還能讓你選擇共享多少個核心出來進行編譯，以前用過真的是很爽，編譯效率大大提高。
它的客戶有: 微軟，谷歌，IBM等等，就這樣看，也算是有一定質量保證吧，畢竟有大廠在使用它。
9樓：張凱(Kyle Zhang)
搭乙個 distcc 集群，配合 ccache，會顯著的提高速度。（記得配ssd！）
標頭檔案也有很大優化空間，可以做，但是比較麻煩。還是 distcc 這種可擴充套件方案比較好。
盡可能用新版本的編譯器，盡可能關閉優化項。（只是除錯的時候關閉，release的時候肯定是要按照需要開啟）
還有就是模版是非常消耗編譯時間的。儘管我覺得沒必要因為編譯慢而放棄使用模版。
10樓：望山
四五千行的C++編譯真不算慢，特別是只做了少量改動的時候。慢的是連線。在出最終版本之前，除錯過程中不要啟用LTO。
我大膽猜想一句，題主該不會連make都沒有用吧？每次修改都全部重新編譯？
11樓：顧笑群
分布式編譯，Windows上和Linux上都有，VS有外掛程式。多個執行緒/程序/核/機器都算。
我們在2023年用VS編譯乙個專案需要2個小時，用了那個VS上的分布式外掛程式後，只需要15-20分鐘。
12樓：fish
如果是指gcc的話，推薦用CMake來編譯，比makefile語法簡單，自動搞定生成.o檔案和增量編譯。
如果是執行一次全量編譯，覺得慢的話，用make -j4，其中4是你cpu的核數，這執行的是多程序編譯。
如果覺得多程序編譯還太慢，可以上ssd。
上了ssd還覺得慢，少用模板。
去了模板還太慢，換電腦。或者考慮放在另一台電腦來編譯。就算慢也不卡你電腦哈。
13樓：
基礎方法都試完了之後，可以試試IncrediBuild。 Accelerate Software Builds and Development Tools
14樓：張地獄
這件事情Unreal Engine4已經想到了。樓上的辦法都不能徹底解決問題。。。
樓主建議看看Unreal4怎麼做的。。不過估計你做不到那樣
15樓：知道得太少
vs有個外掛程式，可以做聯合編譯。同發區域網內的電腦都能參與進來。然後會快很多，原來編譯一次半小時，聯合一下幾分鐘搞定。
再結合樓上說的增量編譯，基本能做到在可接受範圍內吧。編譯的時候去尿一泡回來一般就好了。
外掛程式名叫：incredbuild，是收費的。當年我用的是盜版的。
16樓：jiangtao9999
pch ？
印象裡以前 distcc 做 cross 編譯，這東西會影響必須關掉。
但是詳細檢視了介紹，這個其實是加快編譯速度的，編譯時如果有是被引用的標頭檔案，就預編譯乙個備份，其他程式再編譯引用到這個標頭檔案時，就用快取的預編譯備份直接扔過去，減少重複編譯。
17樓：
GCC 5.x受了「刺激」從C切換到C++
Requirements - state-removal 0.1 documentation
LLVM一直用C++，每次在本地編譯的時候，特別是開啟Debug，我就會逛知乎打發時間，就像現在這樣 :) 或者公司可以上40核編譯伺服器 make -j40 但是我還是習慣在本地編譯測試好先，再提交到編譯器伺服器上，以免犯低階錯誤逃）
編譯 C 專案時模板引發的 undefined reference to 問題？
葛堯 C 中的模板類宣告標頭檔案和實現檔案分離後，如何能實現正常編譯？如果你是把模版類的宣告和定義分開在 h和.cpp裡，就會有這個錯誤，建議你看看上面問題。 麥克阿瑟 undefined reference to TransparentBlt 用codeblocks編寫報錯，標頭檔案中新增了 pr...
大學C語言課程要怎麼學？
對程式設計沒啥興趣你學了通訊.好吧，通訊應該會開很多和計算機類似的課程。如果還想自學C語言，可以看看程式設計入門 C語言 浙江大學 中國大學MOOC 慕課 其實教材只是講個概念，我建議你可以去圖書館找純習題書，最好是分章節的習題，比如說你看完C語言的資料型別，那麼這一章節的習題全部是關於資料型別的，...
當離專案結束時間特別緊，老闆或客戶又臨時要增加乙個非剛性需求時候，該如何說服老闆或客戶不做這個需求？
雄鷹 當離專案結束時間特別緊，老闆或客戶又臨時要增加乙個非剛性需求時候，該如何說服老闆或客戶不做這個需求？從你的問題上可以看出你面臨的是專案實施時間緊張，在這種情況下作為專案經理一定是不希望有半點的新增的需求來影響專案的進度。尤其在專案的後期的需求的調整 剛性非剛性一般是專案經理主管的判斷，這其實並...