win10系統
一旦除錯就會
工具內的編輯器選項應該開的都是yes
uj5u.com熱心網友回復：
tools->compiler options->settings->linker->generate debugging information要設定為yes，然后execute->rebuild all重新生成。uj5u.com熱心網友回復：
不要用DEV了，最差也要C++BUilderuj5u.com熱心網友回復：
我炒，CB成了底線了，這事整的。其實CB現在很強大，編譯器基于clang/llvm修改的，兼容性也很好，基本上除了不免費就沒啥缺點了。uj5u.com熱心網友回復：
他說的最差，打是親罵是愛。
uj5u.com熱心網友回復：
好比說犬子
uj5u.com熱心網友回復：
全打上勾之后除錯就這樣了
uj5u.com熱心網友回復：
你用TMD，你可以用UltraStudio或Eclipse CDT
uj5u.com熱心網友回復：
是TDM好不？
uj5u.com熱心網友回復：
我用dev-c++標準安裝包是好的，沒有任何問題。樓主這個顯示TDM-GCC 4.9.2 32-bit profiling的估計是修改版本，替換了標準安裝包中的GCC（自帶的是gcc 3.4.2，比較老）。uj5u.com熱心網友回復：
所以我想知道不改變編譯器的情況下，如何能解決這個問題uj5u.com熱心網友回復：
換了個版本解決了不容易啊
uj5u.com熱心網友回復：
你下載TDM，再裝eclipse CDT，本身默認就支持TDM,你可以試一下，用ultrastudio也支持，這些我以前都試過。uj5u.com熱心網友回復：
如果以上步驟仍然未解決問題，則是可能是作業系統zlib1.dll 檔案丟失了。下載后放至C:\windows\system32目錄下就可以了
uj5u.com熱心網友回復：
也別太寵了。。我現在最畝訓的就是兩點：
1.時不時崩潰的IDE
2.寫代碼時，自動提示那個慢啊。。。為什么DELPHI的自動提示那么快。。。。。
uj5u.com熱心網友回復：
為什么VS代碼提示那么快，都是C++啊。。。但是用VS做界面簡直是折磨，真的折磨。。。uj5u.com熱心網友回復：
抓主要矛盾。。其它就認了。uj5u.com熱心網友回復：
因為vs的提示是靜態的，而CB、Delphi的提示是動態的，有實時語法檢查。
uj5u.com熱心網友回復：
1.為什么BCB不做成靜態的
2.同樣是動態的話，為什么DELPHI的語法提示要快很多，幾乎和VS一個速度，而BCB卻很慢
uj5u.com熱心網友回復：
因為CB專案里可以直接使用Delphi單元，所以必須也能提示Delphi語法的東西，就使用一樣的技術了。靜態實作是基于知識庫+源代碼掃描，實質就是文本搜索，動態實作除了文本搜索，還有語法掃描，能實時檢查出語法錯誤，所以敲代碼的時候有時在IDE下方的訊息視窗中會出現Unable to invoke Code Completion due to errors in source code，另外即便沒有原始碼，動態實作也能從.lib、.obj、.dcu得到資訊。uj5u.com熱心網友回復：
難道用CB還要裝個固態硬碟。。。。
uj5u.com熱心網友回復：
裝個固態肯定有用啊，另外記憶體要大。uj5u.com熱心網友回復：
據說Delphi編譯也比CB快的多，所以語法掃描應該更快，提示也就快了。uj5u.com熱心網友回復：
那是啊，Delphi的前首席科學家Allen Bauer到google負責chrome專案都抱怨C++編譯太慢，20核40執行緒的E5 build一次要幾小時。
uj5u.com熱心網友回復：
C++的語法特性不比Delphi多多少吧，為什么編譯速度差這么多？uj5u.com熱心網友回復：
我瀏覽器問題都參考不了，偶爾又可以。uj5u.com熱心網友回復：
主要是語言設計的問題，從編譯原理的角度，C++無法用LR(k)決議器實作語法掃描，這里k是一個定值，代表語法掃描時需要預看的單詞數量，更簡單的語言比如C，實際上可以用LR(1)決議器實作，而C++是LR(n)，n是不確定的值，理論上可以無窮大。早期的Delphi，大約D1~D7這個時代的語法，是可以用LL(1)決議器實作語法掃描的，LL要比LR快很多，但是后來的語言特性，像匿名函式、泛型之類復雜的語法，我感覺用LL(1)實作不了，不過我水平有限，也不敢肯定。
uj5u.com熱心網友回復：
涉及到編譯原理，不太懂~
LL和LR是什么區別？
uj5u.com熱心網友回復：
最大的區別是自頂向下(LL)和自底向上(LR)uj5u.com熱心網友回復：
為什么Delphi用LL決議器，C++用LR呢？uj5u.com熱心網友回復：
兩者都可以，LR決議器應對歧義語法的能力更強一些，比較適合C++這樣的語言。編譯原理上經常用到的一個工具yacc，就是LR決議器（LR的一個變體LALR(1)），也能決議Pascal類的語法，另一個決議器生成工具antlr，則是使用LL決議器應對一切語言。uj5u.com熱心網友回復：
看來我的知識老化了。在我上學的那個時期，gcc還使用yacc生成決議器，所以肯定是LR決議器沒問題，不過剛看了一下gcc 7.2的原始碼，其決議器gcc7.2.0\gcc\cp\parser.c（一個1.2MB的恐怖C原始碼）里面明確說了“The parser is of the standard recursive-descent variety”，應該是某種LL決議器，而不是LR。繼續搜索了一下，發現gcc從2004年10月開始就使用了新的語法決議器，不再使用yacc自動生成，繼續搜索，發現clang也使用的LL決議器，也許現在主要語言都不使用LR決議器了，我感覺學過的編譯原理已經過時了...
uj5u.com熱心網友回復：
一個決議器的C原始碼就要1.2MB，大概多少行？編譯器除了決議器，還包括哪些部分呢？聯結器應該比較簡單吧？
個人覺得原理不會過時，技術有發展、有變體，像老子說的那樣，道生一，一生二，二生三，三生萬物。。
uj5u.com熱心網友回復：
39035行，決議器只到語法分析階段，之后還有語意分析，代碼生成、優化。聯結器比較簡單，而且與語言無關，相當于把零件組裝成產品。uj5u.com熱心網友回復：
這幾個階段最復雜的是哪些階段？
uj5u.com熱心網友回復：
作業量：語法分析>語意分析>詞法分析，難度：語意分析>=語法分析>詞法分析，代碼生成、優化的復雜度變動很大，依據編譯器不同，差別很大。轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/50654.html
標籤：基礎類