我的整个应用程序（相当大，具有20MB可执行文件）是用非托管C ++编写的。 因为我可以清楚地看到使用托管代码的优势，我想开始在我的应用程序中引入托管代码，但是我从哪里开始呢？
我可以轻松地开始使用C ++ / CLI并将其与我的应用程序的其余部分链接吗？ （虽然C ++ / CLI语法看起来很“奇特”）。
或者转到C＃是否更好，但是将这与我的非托管C ++代码“链接”的最佳方式是什么？
使用/ clr选项编译所有C ++代码是否有意义？这有用吗？
我是否担心编组？这是否会产生开销，或者我可以在托管和非托管之间切换而不会造成性能损失（正如我20年前混合fortran和C时所做的那样）。性能在我的应用程序中非常重要，因为它是一个科学应用程序，有时会处理几千兆字节的内存。
或者只重新设计用户界面才有意义，只在C＃中编写，并将我的应用程序的其余部分（计算逻辑，业务逻辑，数据库接口......）保存在非托管C ++中？
由于我的应用程序有时需要处理几千兆字节的内存，所以我有一个64位的版本。拥有64位托管代码是否容易？如果使用那么多内存，垃圾收集器是否仍然有效？
简单地说明：我从哪里开始？
帕特里克
答案 0 :(得分：1)
对应用程序进行概要分析，确定您可以使用哪些集成点来捕捉C＃逻辑行并进入C ++，反之亦然。将这些安排到一个计划中，使Facade设计模式在系统中逐步用C＃替换C ++。关键问题是决定在每个候选Facade /接口切换语言时的CPU和内存成本。
您希望能够合并编辑，以便最好使用原始C ++代码的一个源代码集和源代码存储库以及外观和C＃的另一个集合和存储库。
然后，当托盘中有增强/维护工作时，您将其应用于两个代码库，并尝试确保外观在系统中移动，从最不可能改变增强或维护的代码开始，以最大限度地减少倍增变化的工作。
理想情况下，你的工作也是如此的结构，这样你可以回滚立面，如果遇到障碍就可以回到100％C ++。
要测试是否可以将一些特别难以理解的C ++模块分成C ++片段和C＃片段，请在使用管道或套接字进行通信的两个不同的Win32 C ++进程中运行它们。通过这种方式，您可以更好地了解内存管理或性能是否存在需要修复的问题，然后再分割调用链。
答案 1 :(得分：1)
我们完全按照您在数千名用户使用的关键任务应用程序中所描述的内容执行操作。基本上，我们保持现有应用程序不变，因此可执行文件仍然是100％非托管可执行文件（不是C ++ / CLI）。然后我们将所有新的C＃代码放在.NET dll中，其中包括业务对象，用户控件和gui代码等....
基本上，所有新代码都是用C＃编写的。我们有1个dll是C ++ / CLI，只是胶水。这使我们可以轻松地在托管代码和非托管代码之间进行交互，而无需使现有的C ++代码成为可能。这限制了我们必须编写的C ++ / CLI代码量。本机代码与混合模式代码对话，混合模式代码可以与托管代码进行通信。混合模式dll可以挂钩C＃类上的事件，因此C＃代码可以触发事件以与C ++ / CLI（可以与本机代码通信）进行通信。
我们还可以在现有的C ++应用程序中托管.NET UserControls（WinForms只是WINAPI的一个包装器，所以它运行得很好）。
这非常有效，可让您保留现有代码，而无需在C＃中重写整个GUI。
答案 2 :(得分：1)
目前，请考虑关闭此问题。
我意识到答案不是混合C ++和C＃，而是首先让架构正确。
如果架构是正确的，并且在需要分离的地方分开，那么应该更容易通过其他模块（外部，其他语言......）更改应用程序的各个部分。
关于编组期间的性能问题，我们将不得不等到.Net进一步成熟。