2

問題的動機:生成64位和32位代碼需要兩個獨立的完整程序編譯,並且在使用visual studio(如下所述)時發佈和調試版本不兼容,因此看起來需要另外兩個全程序編譯(總計最多四個)。我想堅持兩個完整的程序編譯,但我很困惑。帶有發佈代碼的MSVC混合調試代碼

當調試我所關心的是:導致崩潰的代碼的全局狀態,堆棧幀和行號/文件。另外,我不關心來自同行評審的高度穩定的開源庫的調試信息;因此,我不需要這些庫的調試信息,並且此庫的發佈版本應該足夠。

證據:我知道,在VS中,如果您編譯應用程序的調試版本並將其與Google協議緩衝區的發佈版本鏈接,則生成的代碼將因混合版本的副作用而失敗/調試類型。

我想知道這是否是使用visual studio的副作用,並且一組編譯器開關是如此。

其次,檢查開源項目的構建腳本/過程似乎可以將在調試模式下生成的代碼與在發行版中生成的代碼混合(例如mumble)。我想這與發行版和ReleaseWithDebugInfo(從cmake借用的術語,但在Visual Studio中顯然可表達)之間的區別有關。 ReleaseWithDebugInfo是最後一個二進制文件的優化版本,並且還生成了調試信息,因此適合發佈。

的問題:

  1. 可能有人請解釋一下,或提供參考,至於什麼開關使代碼不兼容。
  2. Visual Studio中的ReleaseWithDebugInfo編譯風格是否足以支持調試和發佈用例(根據我的標準,如上所述)? - 也就是編譯器在調試模式下產生的過度殺傷或冗餘?
  3. 在ReleaseWithDebugInfo模式下(對於我的應用程序)我可以在發佈模式下編譯外部依賴項(沒有調試信息)並且沒有任何未定義的行爲?

回答

3

無論調試模式(我認爲你的意思是未優化)代碼是'過度殺毒'取決於你想要做什麼。

如果你想使用調試器,非常準確地調整行數並檢查你遇到的任何變量,你需要關閉優化。如果你對此不太在乎,那麼你可以把它打開,並在調試器中使用一些奇怪的行爲。

如果編譯爲edit-and-continue,則會在該位置放置大量填充以允許部分編譯/鏈接。

因此,對未優化的代碼有很多「過度衝突」和「冗餘」,但它們可能仍然有價值。

鏈接不同配置的常見問題是當它們共享由運行時庫的不同版本/配置分配的對象時。如果你在庫之間使用Win32風格的'C'風格的接口,那麼你很少關心它的調試和發佈。如果你使用一個版本的運行時在堆上分配一個CString,然後將它傳遞給代碼,並用不同的運行時釋放代碼,那麼通常會出現問題。

有你需要考慮這裏三個不同的東西:

  • 我需要調試符號? - 您可以在任何調試/發佈配置中進行設置
  • 我需要良好的可調試性嗎?還是需要良好的代碼優化?
  • CRT/STL /每個人都在使用什麼版本?

這只是你真正需要完美的最後一個。另外兩個是個人喜好。

+0

CRT版本我遺漏了,謝謝(它提出了另一個維度的問題:D)。你知道爲什麼一個庫的發佈版本會導致另一個庫的調試版本產生一個故障二進制文件? (在我的例子中)CRT與C風格的接口應該是相同的天氣協議緩衝區在發佈版或調試版中編譯。 – 2010-11-09 13:04:55

+0

我不知道任何有關協議緩衝區的細節。在Debug中分配和在Release中釋放(或者相反)的一般問題是它們可能使用不同的塊頭來進行分配(或執行不同的有效性檢查) – 2010-11-09 15:12:37

+0

謝謝您回覆我,是否執行了分配函數是CRT的一部分,還是由編譯器生成的代碼?我只想知道具體情況,所以我知道具體要避免什麼。例如,如果修復了這種差異,我仍然可以得到調試版本與發佈CRT鏈接,同時仍然獲得高度可調試的應用程序。 – 2010-11-09 16:29:56