您是否推薦將Native C++轉換爲C++ \ CLI？

Question

我在過去的幾年中一直是一名本地C++程序員。現在我們從頭開始一個新項目。那麼，如何轉向使用C++ \ CLI的想法是以犧牲平臺獨立代碼爲代價的。通過轉向C++ \ CLI可以獲得什麼特別的優勢嗎？

Answer 1

我建議以下，根據我使用C++，C＃和.NET體驗：

• 如果你想要去的.NET的方式，使用C＃。
• 如果您不想使用.NET，請使用傳統的C++。
• 如果您必須將傳統C++與.NET代碼連接起來，請使用C++/CLI。與.NET調用C++類和調用.NET類的C++一起使用。

如果你不需要它，我認爲只要去C++/CLI是沒有意義的。

Answer 2

你有什麼好處嗎？您可能會失去切換到另一個操作系統的能力。

Answer 3

除非您與.NET應用程序集成，否則不要打擾。當然，不要使用STL/CLR，因爲它的性能確實很糟糕。

它傾向於將該開關翻轉爲使用.NET類庫，但也有其他選擇。如果你這樣做，你將無法輕鬆移植你的代碼。

它似乎也是OSS的崛起正在增加，所以現在可能是使用跨平臺庫和工具進行調查的時候了。您可以比Windows更輕鬆地部署Linux應用程序（通過發佈完全配置的操作系統！），並且如果您部署Linux客戶端（因爲它們是免費的），您將獲得更好的ROI。

如果我是一個商人，我會希望至少有能力部署在Linux或Mac上，而不僅僅是windows-only。從戰略上講，我不想打賭5年後這個世界與微軟保持着同樣的關係。

Answer 4

一些問題交換之前，需要考慮：

[1]你罰款堅持到Windows？有其他操作系統的.NET克隆，但你的應用程序不會運行透明。您可能不需要的複雜性。

[2]您是否正在考慮僅針對垃圾回收支持進行切換？如果是這樣，你可以使用一些C++垃圾收集器庫。如果你弄清楚如何利用std :: shared_ptr，你可能不會覺得需要垃圾收集器。您可能不需要的開銷。

[3]您是否正在考慮C++/CLI，因爲垃圾回收&所有有用的.NET類都可以利用？如果是這樣，爲什麼不切換到C＃。 C++/CLI是一種過渡技術，最好不要在這些方面投入資源。 C＃正變得非常成熟和可用。個人而言，我只會堅持使用C++;）。

Answer 5

您將轉移到C++/CLI的主要優點是訪問.NET庫和框架本身（垃圾回收等）。但是，據我所知，C++/CLI存在的主要原因是爲了簡化將現有C++代碼移植到.NET框架中的運行。鼓勵新項目使用C＃。

如果您需要使用與.NET框架混合的現有C++代碼，那麼使用C++/CLI是有意義的，但一般而言，您應該從C＃開始。

如果在.NET中有新的項目需要廣泛使用（也許更簡單的GUI設計或其他），然後使用C＃。如果沒有，那麼堅持使用本機C++。我不認爲你會因此而失去任何東西。

Answer 6

我非常不喜歡C++/CLI，所以我建議轉向清楚，因爲我描述了here。一些人建議使用C++/CLI作爲標準C++和C＃之間的橋樑，但是由於C++/CLI的設計方式，使用這種方式非常繁瑣（你必須手動創建可以調用的普通C++代碼的包裝器C＃）。因此，我建議使用SWIG代替標準C++與C＃的接口（儘管承認SWIG具有實質的學習曲線）。

Answer 7

那些兩篇文章請看：

A Critical Overview of C++/CLI, Part I

A Critical Overview of C++/CLI, Part II

我相信，現在你是 相信，因爲我是C++/CLI是 既不是「成立的C++擴展「 （在許多方面它實際上是C++的子集），也沒有涉及到比其他任何其他C++更多的C++語言 分號和大括號。此外，C++/CLI絕對是面向Windows的編程語言; 這絕對不是一種語言，即一個 Solaris 10服務器或諾基亞手機 將很樂意運行。 它與C++有什麼關係？

Answer 8

使用C++/CLR的一個主要缺點是如果代碼沒有被模糊不清地丟失IP（知識產權）的可能性。總的來說，我同意其他成員在這裏的發言。如果你想要獨立於MS .net虛擬機的可移植代碼，那麼原生C/C++就是最好的選擇。