有没有将C++代码移植到C#代码的工具？

Question

我有几个C++工具，想要移植到.NET平台。请问是否有将C++应用程序移植到C#的工具？

我认为任何自动化工具都会把代码搞得一团糟，所以也许我还应该问一下这是不是一个好主意？

- yamspog

---

最好的移植工具是你的大脑。 - Marlon

最佳移植工具是由精确的语言解析、语义和规则驱动的自动化引擎。请访问http://www.semanticdesigns.com/Products/Services/NorthropGrummanB2.html，了解一项空军不愿意用“你的大脑”完成的任务。 - Ira Baxter

Answer 1

当然，这是一个活跃的市场。从C++转到C#可以使代码编译更加干净，但实际上让它正常工作需要逐行检查，可能会让你感到十分痛苦。个人经验因人而异。

- Hans Passant

Answer 2

1. 键盘。
2. 鼠标。
3. 显示器。
4. 咖啡。
5. 正则表达式搜索和替换。

- Igor Zevaka

Answer 3

这应该是一条评论，但我没有足够的凭据来发布评论。这与您的问题不完全相关，但我认为对您有用。

C ++ -> C＃：从C ++转移到C＃所需的知识

- Jujjuru

Answer 4

更好的问题是，为什么你会只是移植已经工作的代码而不获取附加价值（例如新功能）？这样做的努力几乎肯定会比你预期的更难，并且需要更长时间。最好使用 .Net 的许多互操作能力从 C# 调用你的 c++ 代码。专注于在 C# 中添加新功能，但不要浪费时间移植已经工作的代码。

- Barry Wark

---

实际上，如果你正在迁移复杂的代码，你不应该在此过程中添加新功能。如果这样做，你将面临无法验证它的严重风险。例如，你无法将其与旧系统进行比较。如果你想获得价值，你应该按原样进行迁移，验证它是否正确，然后利用你的新环境。迁移的感觉确实是非常昂贵的，你最好在最后得到一些“新东西”。这是正确的，但如果你不能完成迁移，那么即使除了这些新内容之外还得到了其他东西也毫无意义。 - Ira Baxter

也许我表达得不太好，我的意思是你不应该仅仅为了移植而移植。在CLR的情况下，你可以保留现有的代码，并使用C#添加任何新功能，而不是使用C++。 - Barry Wark

你必须进行成本效益分析。有经验后，你可以轻松地估算出来。已知有许多成功的端口实例，例如Hibernate -> NHibernate和jUnit -> nUnit。这些框架已经拥有广泛的受众，并且满足了在它们被移植到的语言中尚未满足的需求。 - Merlyn Morgan-Graham

迁移到.NET平台可以提供更好的重构可能性。 - bjornhol

Answer 5

我的公司Semantic Designs有一款将C++转换为C#的工具。它可以处理从C++（数据/类声明，可执行语句）到C#的核心语言结构的转换。该翻译工具基于DMS软件重构工具包。

它需要定制才能处理将异构结构（COM调用，您的自定义API等）翻译成C#。任何您可能找到的工具都需要这样的定制；没有现成的工具可以实际上解决您的特定情况的完整集合。

- Ira Baxter

Answer 6

C++/CLI编译器如何呢？它可以将C++代码转换为.NET程序集。最终，您需要重新设计入口点以接受.NET类型（例如System::String而不是经典的char *），但是如果不使用C#，您将更快地进入.NET。此外，C++/CLI和C#之间也有自动转换，但前提是C++代码已经被.NET化（即上述转换为System::String，generic<typename T> System::Collections::Generic::List等）。

- Ben Voigt

---

我不会给这个点踩，因为我认为它可能适用且值得考虑。但是我也不会给它点赞，因为我认为它可能会在许多情况下带来极大的复杂性，而几乎没有好处。留下它半成品，增加你的工作保障 =P - Merlyn Morgan-Graham

如果你的应用程序具有任何关键性和一定程度的复杂性，你不应该在没有完整单元测试套件的情况下进行移植。编写一个单元测试套件应该被考虑为移植成本的一部分... - Merlyn Morgan-Graham

@Ben Voigt：“我不明白有两个实现怎么能保证任何事情”：它确保你知道旧版本中系统应该如何运作，并确保在新版本中仍然是这样。如果你盲目地移植应用程序，那么你只能对它应该如何运作做出假设。“你如何验证第二个测试套件执行与第一个相同的检查？”：你将其移植的方式与移植任何软件的方式相同-不是逐行机械地复制。你需要添加/删除案例，因为应用程序也不会是100％的副本。例如，手动dealloc与GC。 - Merlyn Morgan-Graham

@Merlyn：你恰好证明了我的观点。如果测试套件以“移植任何软件的方式”进行移植，那么最终结果会出现与在移植主代码时出现的相同错误。确保移植后代码的行为方式与之前一致的唯一方法是在移植之前、期间和之后运行相同的测试套件。而且，如果你的应用程序至关重要，你不会删除释放操作，只是让GC来处理它，因为这会导致非确定性。你将希望在所有相同的地方进行确定性清理，而C++/CLI也使这变得更容易。 - Ben Voigt

@Ben Voigt：我认为我们在重复测试套件概念上存在分歧，所以我想我会放弃它。 - Merlyn Morgan-Graham