我有遗留的c++代码,我应该删除不使用的代码。问题是代码库很大。
我如何才能知道哪些代码从未被调用/从未被使用?
我有遗留的c++代码,我应该删除不使用的代码。问题是代码库很大。
我如何才能知道哪些代码从未被调用/从未被使用?
当前回答
如果你使用g++,你可以使用这个标志-Wunused
根据文档:
每当变量未使用时发出警告 除了它的声明,无论何时 函数被声明为静态的,但是 从来没有定义,每当一个标签 声明但未使用,并且每当a 语句计算的结果为 明确没有使用。
http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html
编辑:这里是另一个有用的标志-Wunreachable-code 根据文档:
此选项用于在编译器检测到至少一整行源代码永远不会执行时发出警告,因为某些条件永远不会满足,或者因为它在一个永远不会返回的过程之后。
更新:我在遗留的C/ c++项目中发现了类似的主题死代码检测
其他回答
一种方法是使用调试器和编译器特性,在编译过程中消除未使用的机器代码。
一旦某些机器代码被删除,调试器就不会让你在相应的源代码行上添加断点。因此,您将断点放置在任何地方,并启动程序并检查断点——那些处于“此源未加载代码”状态的断点对应于已消除的代码——要么该代码从未被调用,要么已内联,您必须执行一些最小分析,以找出这两者中哪一个发生了。
至少这是它在Visual Studio中的工作方式,我猜其他工具集也可以做到这一点。
这需要做很多工作,但我认为比手动分析所有代码要快。
有两种未使用的代码:
局部路径,即在某些函数中,某些路径或变量未使用(或使用但没有任何意义,如写入但从未读取) 全局的:永远不会调用的函数,永远不会访问的全局对象
对于第一种类型,一个好的编译器可以帮助:
-Wunused (GCC, Clang)应该警告未使用的变量,Clang未使用的分析器甚至已经增加到警告从未读取的变量(即使使用)。 -Wunreachable-code(旧的GCC,在2010年被移除)应该警告从未被访问的局部块(它发生在早期返回或条件总是计算为true时) 据我所知,没有选项可以警告未使用的catch块,因为编译器通常不能证明没有异常将被抛出。
对于第二种,要困难得多。静态地,它需要整个程序的分析,即使链接时间优化实际上可以删除死代码,在实践中,程序在执行时已经进行了如此多的转换,以至于几乎不可能向用户传递有意义的信息。
因此有两种方法:
The theoretic one is to use a static analyzer. A piece of software that will examine the whole code at once in great detail and find all the flow paths. In practice I don't know any that would work here. The pragmatic one is to use an heuristic: use a code coverage tool (in the GNU chain it's gcov. Note that specific flags should be passed during compilation for it to work properly). You run the code coverage tool with a good set of varied inputs (your unit-tests or non-regression tests), the dead code is necessarily within the unreached code... and so you can start from here.
如果您对这个主题非常感兴趣,并且有时间和意愿自己开发一个工具,我建议您使用Clang库来构建这样一个工具。
使用Clang库获取AST(抽象语法树) 从入口点开始执行标记-清除分析
因为Clang将为您解析代码,并执行重载解析,所以您不必处理c++语言规则,并且您将能够集中精力处理手头的问题。
然而,这种技术不能识别未使用的虚拟覆盖,因为它们可能由您无法推理的第三方代码调用。
我不认为它可以自动完成。
即使使用代码覆盖工具,也需要提供足够的输入数据来运行。
可能是非常复杂和昂贵的静态分析工具,如Coverity的或LLVM编译器可能会有所帮助。
但我不确定,我更喜欢手动代码审查。
更新
嗯. .不过,仅删除未使用的变量和未使用的函数并不难。
更新
看了其他人的回答和评论后,我更加坚定地认为这是不可能的。
您必须了解代码以获得有意义的代码覆盖率度量,如果您知道大量的手动编辑将比准备/运行/检查覆盖率结果更快。
这取决于创建应用程序时使用的平台。
例如,如果你使用Visual Studio,你可以使用像. net ANTS Profiler这样的工具来解析和分析你的代码。通过这种方式,您应该很快知道实际使用了代码的哪一部分。Eclipse也有等效的插件。
否则,如果您需要知道最终用户实际使用了应用程序的哪些功能,并且您可以轻松地发布应用程序,则可以使用日志文件进行审计。
对于每个主要函数,您可以跟踪它的使用情况,并在几天/一周后获取日志文件,并查看它。
CppDepend是一个商业工具,它可以检测未使用的类型、方法和字段,以及做更多的事情。它适用于Windows和Linux(但目前不支持64位),并有两周的试用期。
免责声明:我不在那里工作,但我拥有这个工具的许可证(以及NDepend,它是。net代码的一个更强大的替代方案)。
对于那些好奇的人来说,这里有一个内置的(可定制的)检测死方法的规则示例,用CQLinq编写:
// <Name>Potentially dead Methods</Name>
warnif count > 0
// Filter procedure for methods that should'nt be considered as dead
let canMethodBeConsideredAsDeadProc = new Func<IMethod, bool>(
m => !m.IsPublic && // Public methods might be used by client applications of your Projects.
!m.IsEntryPoint && // Main() method is not used by-design.
!m.IsClassConstructor &&
!m.IsVirtual && // Only check for non virtual method that are not seen as used in IL.
!(m.IsConstructor && // Don't take account of protected ctor that might be call by a derived ctors.
m.IsProtected) &&
!m.IsGeneratedByCompiler
)
// Get methods unused
let methodsUnused =
from m in JustMyCode.Methods where
m.NbMethodsCallingMe == 0 &&
canMethodBeConsideredAsDeadProc(m)
select m
// Dead methods = methods used only by unused methods (recursive)
let deadMethodsMetric = methodsUnused.FillIterative(
methods => // Unique loop, just to let a chance to build the hashset.
from o in new[] { new object() }
// Use a hashet to make Intersect calls much faster!
let hashset = methods.ToHashSet()
from m in codeBase.Application.Methods.UsedByAny(methods).Except(methods)
where canMethodBeConsideredAsDeadProc(m) &&
// Select methods called only by methods already considered as dead
hashset.Intersect(m.MethodsCallingMe).Count() == m.NbMethodsCallingMe
select m)
from m in JustMyCode.Methods.Intersect(deadMethodsMetric.DefinitionDomain)
select new { m, m.MethodsCallingMe, depth = deadMethodsMetric[m] }