从C移植到C++时我应该记住什么

将项目从C转换为C++时,我应该记住什么？是否有任何理由使用C？我现在唯一想到的是确保它对DLL很友好,所以我可以在需要时创建一个C接口.

注意:我知道C++就好了.模板,部分特化,为什么多重继承是坏的(我只看到一个正确的用途),等等.我主要想知道为什么我会使用C over C++.DLL和脚本语言绑定是一个原因.所以我只需要记住,我应该为某些事情设置一个C接口.还有别的事吗？

显而易见的风险,我要说的是要记住的主要事情是不要修复任何未破坏的东西.

如果你有一个工作的C库,并希望它有一个更"C++ ish"的接口,那么将它包装在类中可能比转换它更聪明.当然这满足了提供DLL友好的C接口的要求:保留你已经拥有的那个.

作为一名C程序员,当C++程序员试图将C语言"移植"到C++时,我觉得很烦人.虽然使用C++语言结构有许多优点,但它们并不总是改进C的简单面向函数的方法.因为你总是可以通过C函数获得extern "C",所以几乎没有理由改变工作代码.在我参与过的项目中,围绕C代码创建对象包装器效果很好.这样,核心代码可以在使用任何一种语言的团队之间共享,每个人都可以使用与其环境匹配的界面.我们甚至将一些C++代码"反向移植"到C以鼓励代码重用.

我与几个不同的项目团队合作,这些团队使用围绕C核的C++包装器进行数据库访问.有些团队使用C++而其他团队只使用C,但核心功能在团队之间共享.我们处于维护期,所以即使C团队想要移植到C++也不可行.我已经看到将C转换为C++的尝试导致更长,更复杂,但没有更具表现力的代码.YMMV,当然.

因为在我传递经验之前,我已经将一些C项目移植到C++:

我猜那是你真正的意思是,当你说你是从移植"从已经正常工作的代码使类和对象" C来C++.这可能就是你在做的事情.我想你想要进行移植的原因是为了使代码更具可重用性和可维护性.请记住,我假设这是一个中型到大型项目(至少10000 LOC).

如果是这样,那么我可以想象你会遇到的一些问题,但也是C++中遇到的问题:

在制作它时新引入的错误

'OO'**

由于C是程序性的,因此对于C++中对象意义上的"可重用"是一种判断调用.您有时可能会发现您的初步观察结果不正确.不是因为你的代码没有编译,而是因为逻辑执行不像以前那样.在这种情况下:当你知道你的基本C++对象没有破坏C程序的原始预期逻辑时,测试,测试,测试(递增)并在最后用设计模式完成所有花哨的重构.

内存管理问题

C'S malloc和free和C++的new和delete做的完全不同的东西.您的C++对象分配将取决于您如何重新解释您对C代码正在做什么的理解,因此您需要非常熟练.但最初我会保留malloc和free调用,并用C++抽象它们,除非有一个很好的理由不这样做.因此,一旦您的类被创建并分配和释放内存,您的应用程序将有内存泄漏.这是一个保证,也是您必须逐步测试的原因.

重构和设计模式

我认为有时会有这种诱惑,继承和设计模式,以使代码更"leet".尝试在端口开始时抵制这种诱惑,因为设计模式本质上是一种优化代码的方式,因此它更有效和可维护,但是更难以考虑将C代码移植到C++并考虑设计模式AND重构和"废话现在它不起作用"和"我在使用错误的设计模式之前必须改变它"......正如你所看到的那样它可以很快失控,所以专注于一次做一件事保持移植过程中的错误免费且易于理解,这样您就不会感到不知所措.

全局

您将需要划分全局变量并找出限制其范围的位置.尝试通过一次创建一个简单的C++对象来保留C代码的含义和功能,在命名空间,继承,设计模式等方面没有任何花哨的东西.同样,在代码转换为类之后,我建议做些什么.

您始终可以将原始C代码包含到C++项目中.因此,即使你有一个C库,它有点与C++混淆,只需extern "C" {}用于引用,然后在你的C++代码中调用它.

https://isocpp.org/wiki/faq/mixing-c-and-cpp

将C对象文件与C++对象文件链接也是完全可能的.

这个(链接到c ++ Super-FAQ)基本上就是你所知道的将项目转换为C++并保持传统兼容性.