我已經用C＃廣泛的合作，但是，我開始一個項目，我們的客戶希望在C++而不是C＃寫入所有代碼。這個項目將是託管（.NET 4.0）和本地C++之間的混合。因爲我一直傾向於將C＃用於C++，以滿足我的.NET需求，所以我想知道在使用C＃和託管C++之間是否存在任何重要區別？託管C++（C++/CLI）與C＃/ VB.NET
任何洞察到這一點非常感謝。
編輯查看維基百科的託管C++代碼表明，新規範是C++/CLI，而「託管C++」已棄用。更新了標題以反映這一點。
C++/CLI是一個完全成熟的.NET語言，就像其他.NET語言一樣，它在託管上下文中工作得非常好。就像在C＃中使用本地調用一樣，本地C++和Managed C++可能會導致一些問題。就這點而言，如果你正在使用很多本機C++代碼，我寧願使用C++/C++。其中大部分內容都可以通過不寫C++/CLI來編寫C＃，也不像編寫本機C++那樣編寫。這是它自己的東西。
我已經在幾個C++/CLI項目上工作過，而我所採取的方法實際上取決於將應用程序的不同級別暴露給本機C++代碼。如果應用程序的大部分核心是本機的，並且本地代碼和託管代碼之間的集成點有些模糊，那麼我會在整個過程中使用C++/CLI。 C++/CLI中控件的好處將超過它的問題。如果你確實有明確的交互點可以被修改或抽象出來，那麼我強烈建議使用C＃和C++創建一個C++/CLI橋接層。這樣做的主要原因是C＃的工具比C++/CLI的相應工具更加成熟和無處不在。就這樣說，我一直在努力的這個項目取得了成功，並不是其他人指出的噩夢。
我也會確保你明白爲什麼客戶會朝這個方向前進。如果這個想法是他們擁有大量的C++開發人員，並且他們希望讓他們更容易地編寫託管代碼，那麼我會向客戶提出，學習C＃可能沒有什麼挑戰性，然後學習C++/CLI。
如果客戶認爲C++/CLI速度更快，但它們都編譯爲IL，這只是不正確的。但是，如果客戶端有很多現有或正在進行的本地C++開發，那麼當前的路徑實際上可能是最好的。
這可能是我的無知，但我從C＃本地調用的經驗令人愉快，事實上，由於您大部分時間都不必做太多事情，因此實際上可以忘記。是的，傳遞託管對象可能會很痛苦，但如果您只是使用基本類型和結構，則非常簡單。我一直在這個線程中看到，在C++中本地調用更容易。你能開導我嗎？ – siride
首先你正在做的本地調用是一個沒有對象概念的c api。使用c＃中的C++ apis幾乎是不可能的，因爲名稱會出現問題和其他問題。同樣在C++中，你可以直接控制內存分配分配策略的佈局，....大多數這些東西都可以在c＃中完成，但沒有大量的函數來支持你在C++中的支持。 – rerun
是的，忘記了名稱的改變。這是一個痛苦。 C API很容易，但我從來不需要使用C++ API。現在明白了。 – siride
我用C++/CLI完成了一個項目，我不得不說這是一個可憎的。基本上這是一個WinForms應用程序來管理員工，曲棍球比賽，團隊之間的交易，日曆等，等等......
所以你可以想象我的窗體上有託管控件的數量：日曆/日期時間選擇器，組合箱，電網等
最糟糕的是隻使用C++類型我的後端，並使用管理類型的前端。首先，您不能將std字符串分配給託管字符串。你需要轉換一切。很明顯，你將不得不將它轉換回...
每次我需要填補一個網格，我序列化我的C++集合像vector<std::string>，檢索，在我的用戶界面庫，然後循環槽，並作出新的DataGridRow將它們添加到網格中。這顯然可以在3分鐘內用C＃和一些Linq to SQL完成。
我結束了一個該應用程序+但讓說實話這絕對吸。我無法想象其他應用程序對我來說有多可悲。
，我認爲它會一直比較容易，如果我在我的C使用List<Customer>^（某些對象的管理列表）++而不是總是串的向量之間進行轉換的一切。但我需要保持C++清理託管的東西。
/pissedof
我設想這個項目前進的方式，託管C++將用於該項目的大部分，然而，它可以很容易地變成剛剛描述的確切的前端/後端場景 –
我很認真。這是絕對可怕的。我無法想象使用/銷售這個應用程序或東西。 – Dave
使用所有三個領域（.NET，C++/CLI和C++），我可以說在各個方面我更喜歡使用.NET（通過C＃或VB.NET）。對於應用程序，您可以使用WinForms或WPF（我發現後者更好 - 特別是對於看起來更加用戶友好的應用程序）。
與C++/CLI的一個主要問題是，你沒有所有您在.NET中得到很好的語言功能。例如，C＃中的yield關鍵字和lambda的使用（我不認爲這在C++/CLI中是受支持的 - 不要拘泥於此）。
然而，C++/CLI有一大優勢。那就是你可以創建一個橋樑來允許C＃和C++進行通信。我目前正在研究一個項目，其中很多數學計算和算法已經在C++中編寫（多年），但該公司正在轉向基於.NET的用戶界面。在研究了各種解決方案之後，我得出了C++/CLI遠勝於此的結論。一個好處是，它允許我構建一個API，對於.NET開發人員來說，它看起來像.NET類型一樣工作。
開發應用程序的前端，但是，我真的不推薦C++/CLI。從可用性的角度來看（根據開發人員使用它的時間），這是不值得的。一個大問題是，VS2010 dropped support for IntelliSense for C++/CLI爲了「提高一般智能感知」（我認爲特別針對C++）。如果你還沒有嘗試過，我肯定會建議檢查WPF的應用程序。
是的，在2010年沒有C++/CLI對IntelliSense的支持是我知道的一個問題。雖然智能感知不是必需的，但這很糟糕，因爲我每天都依賴它來作爲工作流程的一部分。 –
使用WPF「不可行」，因爲正如另一條評論所指出的那樣，客戶端需要學習它。但是，爲什麼我不能像使用C＃或VB.NET一樣使用Designer來將快速接口放在一起呢？對於C++/CLI或其他什麼來說它破了？ –
@BasedAsFunk WinForms設計器似乎與在.NET項目中使用的一樣，所以我沒有看到使用它將一個接口原型放在一起時存在問題。 –
...我知道這一點。我更喜歡使用C++/CLI可能用於.NET框架的怪癖或額外好吃的東西，而不是使用C＃和VB.NET。舉一個例子，即使它們都使用CLR，C＃和VB.NET之間也有一些小的區別。 –
託管C++的唯一好理由是互操作。事實上，你可以擁有原生的'thunk'（速度可以比託管代碼快很多，例如加密）。使用C++/CLI純模式的IMO毫無用處。 – leppie