考慮這種情況： 的應用程序鏈接到第三方庫A.靜態鏈接針對使用不同版本的C運行時庫構建的庫，好還是壞？
A正在使用MSVC 2008年建成並靜態鏈接到C運行時庫9.0（即用/ MT建）。
該應用程序使用MSVC 2005構建，靜態鏈接到A和（使用/ MT）到C運行時庫v8.0。
我可以看到這個問題 - 例如，如果類型在運行時庫版本之間的標頭中更改。
是否注意保持版本之間的運行時庫標頭兼容，還是應該始終確保所有靜態鏈接庫鏈接到相同版本的運行時庫？
它應該不成問題。每個庫鏈接到它自己的運行時，並且主要獨立於進程中的其他庫。問題出現在圖書館ABI定義不明確時。如果在一個庫中分配了任何類型的堆分配對象，通過庫邊界並在另一個庫中「釋放」，則會出現問題，因爲正在使用不同的堆管理器從用於分配的堆管理器中釋放塊它。
任何類型的c運行時定義的結構，對象或實體不應該跨越可能使用不同運行時版本的邊界傳遞： - 從一個庫獲得的FILE *例如對於不同的庫鏈接到不同的運行時間。
只要庫API只使用原始類型，並且不嘗試釋放（）傳入指針，或者傳遞指向內部malloc（）的內存的指針，以使它們期望應用程序（或其他庫）免費（）你應該沒問題。
如果c-runtimes混合存在，那麼它很容易出現「任何事情都可能出錯」的FUD，但是您必須記住傳統上開發了庫和動態庫（.so/.dll/.dylib）以各種語言：允許用asm，c，C++，fortran，pascal等編寫的代碼通過有效的CPU高效二進制接口進行通信。
爲什麼當C連接到C時突然驚慌？
這是一個非常糟糕的計劃。避免。 2005年重新編譯庫或2008年編譯應用程序。
不是一個好主意。您無法控制運行時庫所做的假設以及它們如何實現某些類型。這很可能會造成一種不聖潔的混亂。
讓我困惑的是，可能有很多應用程序鏈接到舊的第三方庫（反過來鏈接到舊的crts）。雖然我同意這看起來很危險，但在實踐中似乎並不危險。 – Viktor 2009-12-09 10:02:28