端口非托管C++项目到C语言

这将花费你更多的转换,而不是包装它,并支付一个自由职业者(像我),以帮助你通过改变你的C++代码每隔几个月(或每隔几年),当你需要作出改变。有一些机械的方法,但更大的问题是,你永远不能确定新的C代码是完全符合旧C++代码所做的。我的客户已经尝试过了,大多数都放弃了工作。成功的人做得很慢,就像这样:

首先,包装旧库并获得用户界面或新代码(Web服务,随便什么),成功地调用旧库。这给每个人带来了“重金”,给你时间来解决“我们不能维护我们的旧代码”问题。您还开发了一个全面的测试套件,它可以证明旧库对各种边缘案例和每隔几年才会在野外发生的奇怪事情所做的工作。随着时间的推移,您将功能从旧库移到新的C库,并更改调用代码以使用新库来实现该功能。你把最不稳定的部分,最经常改变的部分,先出来。在每一个阶段,您都会再次运行测试用例,以确保从C++到C语言的翻译不会使计算结果混乱。也许其中一些你永远不会搬出去,也许最终都会搬出去。当你感到无法维护你自己的图书馆,需要付钱给别人为你维护图书馆的风险已经降到继续翻译的成本以下时,你就停止了。

我建议您在开始时可以访问具有良好C++技能的人。你可能会碰到对你来说不太有意义的事情。但您可以很快地从库中获得价值,并且从长远来看仍然可以解决您的底层问题。

这取决于你所说的港口。

你可以用C重写一些东西。不是所有的。一些HW或遗留库将不得不用C/C++处理,即使您自己输入代码。我不知道有任何可靠的自动转换器用于C++GT;C,我怀疑是否存在。

更好的方法可能是用新的C代码包装现有的代码。例如,您可以在C++/CLI中创建互操作层。或者,如果您不想在同一进程中混合使用本机/托管代码,您可以使用类似于Google协议缓冲区的东西与本机代码进行通信。

我怀疑代码转换工具会有帮助。如果您需要以某种方式在.NET中做一些C++工作,最简单的方法是编写一个管理C++层来封装它,并提供一个用于.NET应用程序的接口。但这取决于代码。

重写的目的是什么?代码是做什么的?它是否与其他组件接口?它有图形用户界面吗?它是独立的可执行文件还是库?它是COM/ActiveX服务器还是使用COM组件?它是否链接到其他DLL或使用第三方库?

所有这些都会影响你如何从零开始移植/重写你的应用程序。例如,如果您的代码是一个MFC应用程序,那么您也可能忘记尝试挽救许多代码。如果你的应用程序有HTTP/高级网络功能,你也可以从头开始写。如果你的代码低级,你可能需要重构一些C和一些C++通过一个管理的C++层访问。

很多选择,这真的取决于你的应用程序在做什么,它是如何写的等等。