解析C ++源代码并将标题内联方法移动到.cpp源文件的工具?

时间:2012-01-13 15:00:53

标签: c++ refactoring inline c++builder automated-refactoring

我们的应用程序的源代码是数十万行,数千个文件,并且在非常古老的地方 - 该应用程序最初是在1995年或1996年编写的。在过去几年中,我的团队已经大大提高了质量。来源,但有一个问题仍然存在,特别是我的错误:许多类在其头文件中完全定义了很多方法。

在某些情况下,我对在标题中内联声明的方法没有任何问题 - struct的构造函数,一种简单的方法,其中内联可测量使其更快(我们有一些像这样的数学函数),等等。但是没有明显理由的自由使用内联方法是:

  • 凌乱
  • 很难找到方法的实现(特别是在类的树中搜索虚函数,只发现一个类在头文件中声明了它的版本...)
  • 可能会增加已编译的代码大小
  • 可能会导致我们的链接器出现问题,即notoriously flaky for large codebases。公平地说,它在过去几年里变得更好,但它并不完美。

最后一个原因现在可能会给我们带来问题,这是通过代码库并将大多数定义移到源文件的充分理由。

我们的代码库非常庞大。 是否有可以为我们做(大部分)此操作的自动化工具?

注意:

  • 我们使用Embarcadero RAD Studio 2010.换句话说,C ++的方言包括VCL and other extensions等。
  • 一些标题是独立的,但大多数标题与相应的.cpp文件配对,正如您通常所做的那样。除了扩展名之外,文件名是相同的,即,如果在X.h中定义了方法,则可以将它们移动到X.cpp。这也意味着该工具不必处理整个项目的解析 - 它可能只是解析各个.cpp / .h文件对,忽略包含等,只要它能够可靠地识别定义了主体的方法在一个类声明中移动它。

4 个答案:

答案 0 :(得分:6)

您可以尝试Lazy C++。我没有使用它,但我相信它是一个命令行工具,可以做你想要的。

答案 1 :(得分:3)

如果代码正常,那么我会投票反对任何重大的自动重写 修复它可能涉及很多工作。

随着时间的推移,小的迭代改进是一种更好的技术,因为您将能够独立地测试每个更改(并添加单元测试)。无论如何,您对无法找到代码的主要抱怨并不是真正的问题,而且已经解决了。已有工具可以为您的代码库编制索引,因此您的编辑器将跳转到正确的函数定义,而无需搜索它。看看你的编辑器的ctags或同等文件。

  • 凌乱

      

    主观

  • 很难找到方法的实现(特别是在虚拟函数的类树中搜索,只发现一个类在头文件中声明了它的版本...)

      

    已有可用于查找功能的工具。 ctags将创建一个文件,允许您从任何体面的编辑器(vim / emacs)直接跳转到该函数。我相信你的编辑如果其中一个人拥有相同的工具。

  • 可能会增加已编译的代码大小

      

    不太可能。编译器将根据内部指标选择内联或不内联,而不是在源中标记为内联的天气。

  • 可能会导致我们的链接器出现问题,这对于大型代码库而言是非常不稳定的。公平地说,它在过去几年里变得更好,但它并不完美。

      

    不太可能。如果你的链接器是flakey,那么它就是flakey,它在定义函数时没有太大的区别,因为如果内联它们没有任何影响。

答案 2 :(得分:1)

您需要解决许多问题:

  • 如何理想地重新组合源文件和头文件
  • 如何自动执行代码修改以实现此目的

在这两种情况下,您都需要一个具有全名解析功能的强大C ++解析器来准确确定依赖关系。

然后你需要能够可靠地修改C ++源代码的机器。

我们的DMS Software Reengineering Toolkit及其C++ Front End可用于此目的。 DMS已用于大规模C ++代码重构;请参阅http://www.semdesigns.com/Company/Publications/并查看第一篇论文“案例研究:通过自动程序转换重新设计C ++组件模型”。 (您可以从那里下载本文的旧版本,但发布的版本更好)。 AFAIK,DMS是唯一一个应用于大规模转换C ++的工具。

SO discussion on reorganizing code解决了直接分组的问题。

答案 3 :(得分:1)

XE2包括一个新的静态分析仪。将新版本的C ++ Builer试用版推出可能是值得的。

相关问题