CRuntime混合非問題似乎沒有解釋，以及如何明智地升級代碼庫

道歉我對這個問題缺乏瞭解。我對我讀過的內容有些不確定，尤其是它與我們現實世界的來源/場景以及如何與之前進有關。CRuntime混合非問題似乎沒有解釋，以及如何明智地升級代碼庫

我之前的一項工作是升級一個古老的VC++代碼庫（目前正在構建並運行Visual Studio 2010項目）以使用VS2013 IDE /編譯器工具。到現在爲止，已經使用VS2010工具& IDE成功開發了大約6年，並且被認爲是穩定的。贏得7/8/10成爲目標。

我開始着眼於VS2013 IDE /編譯器/鏈接器升級的潛在問題，並且遇到了混合CRT庫的問題（大量警告，針對大量問題報告，對我的部分沒有太多關於CRT問題的知識）。由於我們的代碼目前是穩定的，我沒有想到會發現問題，但是下面的（噩夢？）變得相當迅速。

我開始在這裏，這是一個很好的開始大開眼界： http://siomsystems.com/mixing-visual-studio-versions/

，並最終發現，我有以下組合：

Application.exe  statically links LIBCMT.lib using VS2010 toolchain (- but isnt LIBCMT very old, like VC6?) 
lib A   statically links LIBCMT.lib. This is our library. Same as above. 
lib B   statically links LIBCMT.lib. This is our library. Same as above. 
lib C   statically links with "-MT". Not our library (& no clue as to which version of LIBCMT. Could be anything) 
dll 1   dynamically links MSVCRT.dll. Not our dll. (again, isnt this VC6, or very old? Reading suggests could be v4.2 - v6) 
dll 2   as dll1 
Windows dlls...  Many of these. Eg, wininet, depends on MSVCRT.dll (MSVCR1xx version expected, but old MSVCRT referenced!)

（要查找的依賴，我也搜索了lib.exe爲「cl.exe」，並指出了編譯選項或使用過的dumpbin。）

現在，爲了增加我的不確定性，Visual Studio調試器「模塊」窗口只顯示一個MSVCRT.dll。也許這就是爲什麼它看起來很穩定（？） - 但我期望上面顯示的依賴關係起作用 - 而不是這種舊的MSVCRT引用（我已經使用這些庫/ DLL在運行時訪問它們的功能&請參閱否改爲模塊加載）。

所以，我的問題：

明顯，但：做別人分享我對C運行在該應用中明顯的混合關注？
據我所知**，通過dll邊界傳輸的數據類型僅僅是基元的原始數組。在不同CRT中沒有存儲器創建/釋放，沒有文件指針傳遞，沒有要求的環境變量等等，AFAIK。另外，沒有從共享標題實例化的結構。如果我絕對正確的話，這可能是混合CRT可能與我的應用程序一起工作的原因嗎？

**我確實需要徹底檢查一下，並檢查是否屬實。

在移動到VS2013工具鏈（編譯器/鏈接器），I必須考慮到改變我們的exe &庫使用動態CRT。我的想法是儘量減少任何可能的CRT混合，所以我認爲最好的計劃是儘可能多地製作庫，使用單個動態CRT（MSVCR120.dll？） - 因爲我在某處讀取多個動態CRT被加載，一個實際上將被使用。有人可以證實這種情況嗎？這是一個合理的戰略，還是有這樣一個圖書館遺產，是否有更好的方法？

如果一個MSVCRxxx版本要由多個dll/libs加載，我們可以說哪個/哪些應該在任何特定的Windows 7/8/10 pc上？（例如，最舊的版本，最新的版本，首先要求加載？）

我可能在想這個，但網上的各種警告和我看似混合的CRT應用程序都讓我擔心。

我認爲這涵蓋了它。任何意見都非常感謝。

感謝您的閱讀。

編輯2016年7月20日：我只是碰到這種文章，我認爲是相關的任何人來考慮同樣的問題：http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html

謝謝！

來源

2016-05-16 user6340046

如果您的代碼庫編譯，運行並將您的大量回歸測試傳遞給較新的編譯器，那麼問題是什麼？ –

感謝Brain的評論，是的，這是一個很好的觀點，但我表達的關注點是運行時問題不一定會通過測試獲得。這是拉姆斯菲爾德「已知的未知因素」 - 在我看來，它看起來很糟糕，而且（我認爲）應該會引發問題 - 現在不正確，但我覺得我需要理解並制定戰略。我希望那裏的人可能會說，「是的，這很糟糕，把它分類出來...... <這是我該怎麼做>」或「實際上不是問題，因爲......」 – user6340046

問題在你提供的鏈接中是有效的。我親自遇到的唯一一個是內存分配。每個CRT（甚至當靜態鏈接到多個DLL時都是同一個CRT）都有自己的內存分配堆，因此有一個DLL分配內存，而不同的DLL空閒內存會成爲問題。 –

我相信你的＃3策略是最好的方法。在你的例子中的lib C可能是一個問題。如果未在「。」中找到，則加載的Exact DLL由％PATH％環境變量指定。 microsoft DLL search order link. 您可以使用Microsoft的Dependancy walker depends.exe來查看應用程序將使用哪些DLL。

這應該可以解決除LibC外的所有情況。

來源

2016-05-27 12:35:04

嗨羅斯，只是感謝你的回答。最好的問候，D – user6340046

CRuntime混合非問題似乎沒有解釋，以及如何明智地升級代碼庫

回答

相關問題