我们的应用程序的源代码是数十万行,数千个文件,并且在非常古老的地方 - 该应用程序最初是在1995年或1996年编写的。在过去几年中,我的团队已经大大提高了质量。来源,但有一个问题仍然存在,特别是我的错误:许多类在其头文件中完全定义了很多方法。
在某些情况下,我对在标题中内联声明的方法没有任何问题 - struct的构造函数,一种简单的方法,其中内联可测量使其更快(我们有一些像这样的数学函数),等等。但是没有明显理由的自由使用内联方法是:
最后一个原因现在可能会给我们带来问题,这是通过代码库并将大多数定义移到源文件的充分理由。
我们的代码库非常庞大。 是否有可以为我们做(大部分)此操作的自动化工具?
注意:
答案 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试用版推出可能是值得的。