2009-12-17 34 views
6

我的整個應用程序(這是相當大的,有一個20MB的可執行文件)是用非託管C++編寫的。 因爲我可以清楚地看到使用託管代碼的優點,所以我想開始在我的應用程序中引入托管代碼,但我從哪裏開始?我的應用程序是非託管的。我在哪裏開始介紹託管代碼?

我可以很容易地開始使用C++/CLI,並與我的應用程序的其他部分聯繫起來呢? (儘管C++/CLI語法看起來頗爲'異乎尋常')。

或者是更好的移動到C#,但什麼是「鏈接」這與我的非託管C++代碼一起最好的方法是什麼?

是否有意義編譯使用/ CLR選項我所有的C++代碼嗎?這會工作嗎?

我需要擔心編組嗎?這是否會產生開銷,或者我是否可以在沒有性能損失的情況下在託管和非託管之間切換(就像20年前混合Fortran和C時那樣)。性能在我的應用程序中非常重要,因爲它是一個科學應用程序,有時會處理幾千兆字節的內存。

或者它纔有意義,重新設計的用戶界面,並且只寫在C#中,並保持我的應用程序的其餘部分(計算邏輯,業務邏輯,數據庫接口,...)在非託管C++?

由於我的應用程序有時需要處理的內存數千兆字節,我有一個64位的變體。是否容易擁有64位託管代碼?如果使用了大量內存,那麼垃圾收集器是否仍然有效?

簡單地說:我從哪裏開始?

帕特里克

+2

託管C++既不魚也不禽 - 如果可能,我會避免它。 – 2009-12-17 16:36:16

回答

1

目前,請考慮關閉此問題。

我意識到答案並不是混合使用C++和C#,而是將架構正確地放在首位。

如果體系結構是正確的,並且在需要分離的地方分開,那麼比其他模塊(外部,其他語言...)更改應用程序的部分應該更容易。我們將不得不等待.Net進一步成熟。

1

個人應用程序,決定在什麼樣的整合點,你可以折斷邏輯的C#線,並打入C++,反之亦然。將這些安排到計劃中,讓Facade設計模式通過系統逐漸取代C++。當決定在每個候選Facade /接口切換語言時,主要關心的是CPU和內存成本。

你會希望能合併的編輯,所以你可能是最好關閉與一個源代碼集和源代碼庫爲原始的C++代碼,另一組以及倉庫的外牆加上C#。

然後,隨着托盤中的增強/維護工作應用於兩個代碼庫,並且您嘗試確保門面在系統中移動,從代碼開始,最小可能改變增強或維護以最小化加倍改變工作。

也非常構建你的工作,所以你可以回滾門面回到100%的C++在動不動,如果你遇到了障礙。

爲了測試一些特別難以理解的C++模塊是否可以分離爲C++代碼段和C#代碼段,請在使用管道或套接字進行通信的兩個不同的Win32 C++進程中運行它們。通過這種方式,您可以更好地瞭解在此時可以拆分調用鏈之前是否存在需要修復的內存管理問題或性能問題。

1

我們完全按照您在數千用戶使用的關鍵任務應用程序中描述的內容進行操作。基本上,我們保持原有的應用程序,所以可執行文件仍然是100%非託管可執行文件(而不是C++/CLI)。然後,我們將所有新的C#代碼放入由業務對象,用戶控件和gui代碼等組成的.NET dll中。

基本上,所有新代碼都是用C#編寫的。我們有1個dll,就是C++/CLI,它只是粘合劑。這使我們可以輕鬆地在託管代碼和非託管代碼之間進行互操作,而無需製作現有的C++代碼clr。這限制了我們必須編寫的C++/CLI代碼的數量。本地代碼與混合模式代碼進行通信,混合模式代碼可以與託管代碼進行通信。混合模式的dll可以在C#類上掛鉤事件,這樣C#代碼就可以觸發事件與C++/CLI(可以與本機代碼交流)進行通信。我們也可以在現有的C++應用程序中託管.NET UserControls(WinForms只是WINAPI的一個包裝,所以它工作得很好)。

這工作得很好,可以讓您保留現有的代碼,而不必在C#中重寫整個GUI。

相關問題