转换的C源代码C ++ [英] Converting C source to C++

问题描述

您会如何去转换一个相当大（> 300K），相当成熟的C codeBase的，以C ++？

How would you go about converting a reasonably large (>300K), fairly mature C codebase to C++?

种类的CI心目中被分成大致对应于模块（即比典型的OO基于类的分解较少的颗粒）文件，使用内部联动代替私有函数和数据，以及外部连接公共函数和数据。全局变量为在模块之间通信广泛使用。有可用的一个非常广泛的集成测试套件，但是任何单位（即模块）级测试。

The kind of C I have in mind is split into files roughly corresponding to modules (i.e. less granular than a typical OO class-based decomposition), using internal linkage in lieu private functions and data, and external linkage for public functions and data. Global variables are used extensively for communication between the modules. There is a very extensive integration test suite available, but no unit (i.e. module) level tests.

我心中有一个总体战略：

I have in mind a general strategy:

1. 编译C ++了C子集一切，得到的工作。


2. 转换模块集成到巨大的班，让所有的交叉引用由一个类名范围，但留下的所有功能和数据的静态成员，并获得了该工作。


3. 转换巨大类与适当的构造和初始化的交叉引用的实例;取代静态成员与间接访问适当的访问;和获取工作。


4. 现在，接近该项目作为不良因素OO应用程序，并编写单元测试，其中依赖性是容易处理，并分解为单独的类，他们都没有;这里的目标是从一个工作程序在每次转换移动到另一个。

显然，这将是相当多的工作。是否有任何案例研究/战争的故事在那里对这种翻译的？备选策略？其他有用的建议？

Obviously, this would be quite a bit of work. Are there any case studies / war stories out there on this kind of translation? Alternative strategies? Other useful advice?

注1：程序是一个编译器，而且很可能数以百万计的其他程序依靠其行为不改变，那么批发改写为pretty多少不是一个选项

Note 1: the program is a compiler, and probably millions of other programs rely on its behaviour not changing, so wholesale rewriting is pretty much not an option.

注2：源是近20岁，并且有可能是30％code流失每年（修改+添加/ previous共线线）。它在很大程度上保持和扩展，换句话说。因此，目标之一是增加mantainability。

Note 2: the source is nearly 20 years old, and has perhaps 30% code churn (lines modified + added / previous total lines) per year. It is heavily maintained and extended, in other words. Thus, one of the goals would be to increase mantainability.

[对于这个问题的缘故，假定翻译成 C ++ 是强制性的，并把它留在C是的不可以选项。加入这种情况的关键是淘汰了留在C的答案。]

[For the sake of the question, assume that translation into C++ is mandatory, and that leaving it in C is not an option. The point of adding this condition is to weed out the "leave it in C" answers.]

推荐答案

说完刚刚开始pretty同样的事情在几个月前（上十岁的商业项目，原来写的C ++不过下与智能结构的哲学），我会建议使用你会使用吃大象同样的策略：把它一咬一次。 ： - ）

Having just started on pretty much the same thing a few months ago (on a ten-year-old commercial project, originally written with the "C++ is nothing but C with smart structs" philosophy), I would suggest using the same strategy you'd use to eat an elephant: take it one bite at a time. :-)

尽可能，其分解成可与其它部件的影响最小完成阶段。建立一个门面体系，费德里科·Ramponi 的建议，是一个良好的开端 - 一旦任何事物都有一个C ++的门面，并通过它交流，你可以改变模块的内部公平肯定地说，他们不能影响他们以外的任何东西。

As much as possible, split it up into stages that can be done with minimal effects on other parts. Building a facade system, as Federico Ramponi suggested, is a good start -- once everything has a C++ facade and is communicating through it, you can change the internals of the modules with fair certainty that they can't affect anything outside them.

我们已经有了到位（由于previous较小的重构努力）的部分C ++接口系统，所以这种方式对我们来说并不困难。一旦我们拥有一切为C ++对象通信（这花了几个星期，在一个完全独立的源 - code分公司工作，并整合所有改变主要分支，因为他们获得批准），这是很少，我们不能编译完全工作版本，我们离开的前一天。

We already had a partial C++ interface system in place (due to previous smaller refactoring efforts), so this approach wasn't difficult in our case. Once we had everything communicating as C++ objects (which took a few weeks, working on a completely separate source-code branch and integrating all changes to the main branch as they were approved), it was very seldom that we couldn't compile a totally working version before we left for the day.

在切换时尚未完成 - 我们为临时版本暂停两次（我们的目标是一个点释放每隔几个星期），但它是很好的方式，并没有客户抱怨任何相关问题。我们的QA人员只发现了一个问题，我记得了。 ： - ）

The change-over isn't complete yet -- we've paused twice for interim releases (we aim for a point-release every few weeks), but it's well on the way, and no customer has complained about any problems. Our QA people have only found one problem that I recall, too. :-)

这篇关于转换的C源代码C ++的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！