If the code is working then I would vote against any major automated rewrite. Lots of work could be involved fixing it up.
Small iterative improvements over time is a better technique as you will be able to test each change in isolation (and add unit tests). Anyway your major complaint about not being able to find the code is not a real problem and is already solved. There are already tools that will index your code base so your editor will jump to the correct function definition without you having to search for it. Take a look at ctags or the equivalent for your editor.
Messy
Subjective
Makes it hard to find the implementation of a method (especially searching through a tree of classes for a virtual function, only to find one class had its version declared in the header...)
There are already tools available for finding the function. ctags will make a file that allows you to jump directly to the function from any decent editor (vim/emacs). I am sure your editor if nto one of these has the equivalent tool.
Probably increases the compiled code size
Unlikely. The compiler will choose to inline or not based on internal metrics not weather it is marked inline in the source.
Probably causes issues for our linker, which is notoriously flaky for large codebases. To be fair, it has got much better in the past few years, but it's not perfect.
Unlikely. If your linker is flakey then it is flakey it is not going to make much difference where the functions are defined as this has no bearing on if they are inlined anyway.
How to regroup the source and header files ideally
How to automate the code modifications to carry this out
In both cases, you need a robust C++ parser with full name resolution to determine the dependencies accurately.
Then you need machinery that can reliably modify the C++ source code.
Our DMS Software Reengineering Toolkit with its C++ Front End could be used for this. DMS has been used for large-scale C++ code restructuring; see http://www.semdesigns.com/Company/Publications/ and track down the first paper "Case Study: Re-engineering C++ Component Models Via Automatic Program Transformation". (There's an older version of this paper you can download from there, but the published one is better). AFAIK, DMS is the only tool to have ever been applied to transforming C++ on large scale.
发布评论
评论（4）
您可以尝试Lazy C++。我没有使用过它，但我相信它是一个命令行工具，可以做你想做的事情。
You might try Lazy C++. I have not used it, but I believe it is a command line tool to do just what you want.
如果代码有效，那么我将投票反对任何主要的自动重写。
修复它可能需要做很多工作。
随着时间的推移进行小的迭代改进是一种更好的技术，因为您将能够单独测试每个更改（并添加单元测试）。无论如何，您关于无法找到代码的主要抱怨并不是真正的问题，并且已经解决了。已经有一些工具可以为您的代码库建立索引，因此您的编辑器将跳转到正确的函数定义，而无需您搜索它。查看 ctags 或适合您的编辑器的等效工具。
凌乱
<块引用>
主观
凌乱
使得很难找到方法的实现（尤其是在类树中搜索虚函数，结果却发现一个类在标头中声明了其版本...）
<块引用>
已经有可用于查找该函数的工具。
ctags将创建一个文件，允许您从任何合适的编辑器（vim/emacs）直接跳转到该函数。我确信您的编辑器如果其中之一有等效的工具。可能会增加编译代码的大小
<块引用>
不太可能。编译器将根据内部指标选择内联或不内联，而不是在源代码中将其标记为内联。
可能会给我们的链接器带来问题，众所周知，链接器对于大型代码库来说是不稳定的。公平地说，过去几年它已经好多了，但并不完美。
<块引用>
不太可能。如果您的链接器很不稳定，那么它是不稳定的，定义函数的位置不会有太大区别，因为这与它们是否内联无关。
If the code is working then I would vote against any major automated rewrite.
Lots of work could be involved fixing it up.
Small iterative improvements over time is a better technique as you will be able to test each change in isolation (and add unit tests). Anyway your major complaint about not being able to find the code is not a real problem and is already solved. There are already tools that will index your code base so your editor will jump to the correct function definition without you having to search for it. Take a look at ctags or the equivalent for your editor.
Messy
Makes it hard to find the implementation of a method (especially searching through a tree of classes for a virtual function, only to find one class had its version declared in the header...)
Probably increases the compiled code size
Probably causes issues for our linker, which is notoriously flaky for large codebases. To be fair, it has got much better in the past few years, but it's not perfect.
XE2 包括一个新的静态分析器。尝试一下新版本的 C++Builer 可能是值得的。
XE2 includes a new static analyzer. It might be worthwhile to give the new version of C++Builer's trial a spin.
您有许多问题需要解决：
在这两种情况下，您都需要一个具有全名解析功能的强大 C++ 解析器来准确确定依赖关系。
那么您需要能够可靠地修改 C++ 源代码的机器。
我们的 DMS 软件再工程工具包及其 C++ 前端 可用于此目的。 DMS已用于大规模C++代码重组；请参阅 http://www.semdesigns.com/Company/Publications/ 并追踪第一篇论文“案例研究：通过自动程序转换重新设计 C++ 组件模型”。 （您可以从那里下载本文的旧版本，但已发布的版本更好）。 AFAIK，DMS 是唯一一个大规模应用于 C++ 转换的工具。
这个关于重新组织代码的讨论直接解决了分组问题。
You have a number of problems to solve:
In both cases, you need a robust C++ parser with full name resolution to determine the dependencies accurately.
Then you need machinery that can reliably modify the C++ source code.
Our DMS Software Reengineering Toolkit with its C++ Front End could be used for this. DMS has been used for large-scale C++ code restructuring; see http://www.semdesigns.com/Company/Publications/ and track down the first paper "Case Study: Re-engineering C++ Component Models Via Automatic Program Transformation". (There's an older version of this paper you can download from there, but the published one is better). AFAIK, DMS is the only tool to have ever been applied to transforming C++ on large scale.
This SO discussion on reorganizing code addresses the problem of grouping directly.