在混合C++ .NET應用程序中強調託管還是非託管？

Question

我工作的應用程序是一個WinForms應用程序，幾乎全部用Visual C++編寫，大約在2003年。在我到達現場之前，由於UI構建框架，.NET被選中，但絕大多數代碼是在非託管的土地。其中一部分是絕對必要的 - 我們對一些非常大的數據集進行一些實時圖像處理，使用一些需要指向圖像緩衝區的英特爾圖像處理庫，而我們真的是，其中< 1％的情況性能是至關重要的。

該應用程序本身是一個大型的可執行文件，它將UI代碼鏈接到幾個靜態庫，每個庫都對應一個功能子系統 - 數據採集，圖像處理等等。自從我加入後，我通過編寫託管包裝器將這些子系統分成了幾個子系統，我們在其他應用程序中重用，但主應用程序仍然由靜態鏈接庫組成。

我和我的同事對於是否進一步發展應該強調非託管還是管理有很大不同。除了我提到的情況外，沒有規定非託管代碼的性能要求。我們堅定致力於.NET，所以跨平臺不是問題。我認爲我們應該贊成管理，除非另有規定。

上個月，我的同事開發了一套管理子系統的類;而不是將它們作爲ref類實現，並將某些事件添加到.NET接口中，他編寫了Observer的幾個實現，使用gcroot爲託管客戶端提供句柄，並允許自己留在非託管的土地上。這在我看來是錯誤的，只是因爲爲什麼寫一些你可以免費得到的東西呢？但我想知道我是否過於僵化。

有什麼想法？

Answer 1

沒有單一的正確或錯誤的答案，除了說你傾向於管理和你的同事傾向於非託管是絕對錯誤的。無論您選擇哪種方式，您都需要達成一致，才能避免讓代碼管理和代碼管理變得更糟。

你說「我們堅定致力於.NET」。誰是「我們」？是你的公司，還是你和你的同事？這聽起來像你的同事沒有那麼致力於.NET。如果公司承諾並且同事不承諾，那麼有人需要向同事重申他是團隊的一員，需要遵循公司的方向。

如果決定真的取決於您和您的兩位同事，那麼您應該考慮默認。

我們還有一個很大的託管/非託管應用，我們絕不會考慮在非託管方面做任何事情，除非我們絕對必須這樣做。大部分的應用程序是管理的。這樣更好。但這是我的看法，不是事實。

Answer 2

的管理VS非託管編程禪：

良好的非託管代碼將不必在內存管理上的錯誤與等效託管代碼明顯的缺點來舉例說明。

良好的託管代碼將通過在性能上與對等的非託管代碼相比沒有明顯的缺點來舉例說明。

他們倆之間的互操作沒有什麼好處;）