我如何知道代码中的哪些部分从未被使用过？

Question

我有遗留的 C++ 代码，我应该从中删除未使用的代码。问题是代码库很大。

我如何找出哪些代码从未被调用/从未使用过？

Answer 1

未使用的代码有两种：

• 本地代码，即在某些函数中，某些路径或变量未使用（或使用但没有任何意义，例如写入但从未读取）
• 全局代码：从未调用的函数，全局代码

对于第一种类型，一个好的编译器可以提供帮助：

• -Wunused（GCC，Clang）应该警告未使用的变量，Clang未使用的分析器甚至已经增加以警告从未读取（即使使用）的变量。
• -Wunreachable-code（旧版 GCC， 2010 年删除）应该警告从未访问过的本地块（它发生在早期返回或始终评估为 true 的条件下），
• 据我所知，没有选项可以警告未使用的 catch块，因为编译器通常无法证明不会抛出异常。

对于第二种，就困难得多。静态地，它需要整个程序分析，尽管链接时优化实际上可以删除死代码，但实际上程序在执行时已经发生了很大的变化，几乎不可能向用户传达有意义的信息。

因此有两种方法：

• 理论上的一种是使用静态分析器。一款可以立即详细检查整个代码并找到所有流程路径的软件。实际上，我不知道有什么可以在这里工作。
• 务实的方法是使用启发式方法：使用代码覆盖工具（在 GNU 链中是 gcov。请注意，应在编译期间传递特定标志才能使其正常工作）。您使用一组良好的不同输入（您的单元测试或非回归测试）运行代码覆盖工具，死代码必然位于未到达的代码中......因此您可以从这里开始。

如果您对这个主题非常感兴趣，并且有时间和意愿自己实际开发一个工具，我建议使用 Clang 库来构建这样一个工具。

1. 使用 Clang 库获取 AST（抽象语法树）
2. 从入口点开始执行标记和清除分析

因为 Clang 会为您解析代码，并执行重载解析，所以您不必处理 C++语言占主导地位，您将能够专注于手头的问题。

然而，这种技术无法识别未使用的虚拟覆盖，因为它们可能被您无法推理的第三方代码调用。

Answer 2

对于未使用的整个函数（以及未使用的全局变量）的情况，只要您使用 GCC 和 GNU ld，GCC 实际上可以为您完成大部分工作。

编译源代码时，使用 -ffunction-sections 和 -fdata-sections，然后在链接时使用 -Wl,--gc-sections,--print- gc-sections。链接器现在将列出所有可以删除的函数，因为它们从未被调用，以及所有从未被引用的全局变量。

（当然，您也可以跳过 --print-gc-sections 部分，让链接器静默删除这些函数，但将它们保留在源代码中。）

注意：这只会找到未使用的完整函数，它不会对函数内的死代码执行任何操作。从活动函数中的死代码调用的函数也将保留。

一些 C++ 特有的功能也会引起问题，特别是：

• 虚函数。如果不知道哪些子类存在以及哪些子类在运行时实际实例化，您就无法知道最终程序中需要存在哪些虚拟函数。链接器没有足够的信息，因此必须保留所有这些信息。
• 具有构造函数的全局变量及其构造函数。一般来说，链接器无法知道全局的构造函数没有副作用，因此它必须运行它。显然，这意味着全局本身也需要保留。

在这两种情况下，虚函数或全局变量构造函数使用的任何内容都必须保留。

另一个需要注意的是，如果您正在构建共享库，GCC 中的默认设置将导出共享库中的每个函数，从而导致链接器“使用”它。要解决此问题，您需要将默认值设置为隐藏符号而不是导出（使用例如 -fvisibility=hidden），然后显式选择需要导出的导出函数。

Answer 3

如果你使用 g++，你可以使用这个标志 -Wunused

根据文档：

每当变量未被使用时发出警告
除了其声明外，每当
函数被声明为静态但
从未定义，只要标签是
已声明但未使用，并且每当
语句计算的结果是
明确未使用。

http://docs.freebsd.org/info/gcc/gcc。 info.Warning_Options.html

编辑：这是其他有用的标志-Wunreachable-code
根据文档：

此选项旨在当编译器检测到至少一整行源代码永远不会被执行时发出警告，因为某些条件永远不会满足，或者因为它位于永远不会返回的过程之后。

更新：我发现类似的主题旧版中的死代码检测C/C++项目

Answer 4

我认为您正在寻找代码覆盖率工具。代码覆盖率工具会在代码运行时对其进行分析，让您知道哪些代码行被执行了、执行了多少次，以及哪些代码没有被执行。

您可以尝试给这个开源代码覆盖工具一个机会：TestCocoon - 适用于 C/C++ 和 C# 的代码覆盖工具。

Answer 5

这里真正的答案是：你永远无法真正确定。

至少，对于重要的情况，你无法确定你已经了解了所有内容。请考虑维基百科关于无法访问代码的文章中的以下内容：

double x = sqrt(2);
if (x > 5)
{
  doStuff();
}

正如维基百科正确指出的那样，聪明的编译器可能能够抓住这样的东西。但考虑一下修改：

int y;
cin >> y;
double x = sqrt((double)y);

if (x != 0 && x < 1)
{
  doStuff();
}

编译器会捕获这个吗？或许。但要做到这一点，它需要做的不仅仅是针对常量标量值运行 sqrt 。必须弄清楚 (double)y 始终是整数（简单），然后了解整数集的 sqrt 数学范围（困难） 。一个非常复杂的编译器可能能够为 sqrt 函数，或者为 math.h 中的每个函数，或者对于其域可以计算的任何固定输入函数执行此操作出去。这变得非常非常复杂，而且复杂性基本上是无限的。您可以不断地向编译器添加复杂的层，但是总会有一种方法可以潜入一些对于任何给定的输入集都无法访问的代码。

还有一些输入集永远不会被输入。输入在现实生活中没有意义，或者被其他地方的验证逻辑阻止。编译器无法知道这些。

最终结果是，虽然其他人提到的软件工具非常有用，但除非您事后手动检查代码，否则您永远无法确定您是否捕获了所有内容。即便如此，您也永远无法确定自己没有错过任何事情。

恕我直言，唯一真正的解决方案是尽可能保持警惕，使用您可以使用的自动化功能，尽可能进行重构，并不断寻找改进代码的方法。当然，无论如何这样做都是个好主意。

Answer 6

我自己没有使用过，但是 cppcheck，声称找到未使用的功能。它可能无法解决完整的问题，但它可能是一个开始。

Answer 7

您可以尝试使用Gimple Software 的 PC-lint/FlexeLint。它声称

查找未使用的宏、typedef、
类、成员、声明等
贯穿整个项目

我使用它进行静态分析，发现它非常好，但我必须承认我没有使用它来专门查找死代码。

Answer 8

我查找未使用内容的常规方法是

1. 确保构建系统正确处理依赖项跟踪
2. ，设置第二个监视器，带有全屏终端窗口，运行重复构建并显示第一个屏幕的输出。 watch "make 2>&1" 在 Unix 上往往能达到目的。
3. 在整个源代码树上运行查找和替换操作，在每行的开头添加“//？”
4. 通过删除“//？”来修复编译器标记的第一个错误在相应的行中。
5. 重复直到没有错误为止。

这是一个有点漫长的过程，但确实带来了良好的结果。

Answer 9

将尽可能多的公共函数和变量标记为私有或受保护，而不会导致编译错误，同时尝试重构代码。通过将函数设为私有并在某种程度上受到保护，您可以减少搜索区域，因为私有函数只能从同一个类中调用（除非存在愚蠢的宏或其他技巧来规避访问限制，如果是这种情况，我建议您找到一份新工作）。确定您不需要私有函数要容易得多，因为只有您当前正在处理的类可以调用此函数。如果您的代码库具有小型类并且松散耦合，则此方法会更容易。如果您的代码库没有小类或耦合非常紧密，我建议首先清理它们。

接下来将标记所有剩余的公共函数并制作调用图以弄清楚类之间的关系。从这棵树上，尝试找出树枝的哪一部分看起来可以修剪。

这种方法的优点是，您可以在每个模块的基础上执行此操作，因此很容易继续通过单元测试，而无需在代码库损坏时花费大量时间。

Answer 10

如果您使用的是 Linux，您可能需要研究一下 callgrind，这是一个 C/C++ 程序分析工具，它是 valgrind 套件的一部分，该套件还包含用于检查内存泄漏和其他内存错误（您也应该使用它们）。它分析程序的运行实例，并生成有关其调用图以及调用图上节点的性能成本的数据。它通常用于性能分析，但它也会为您的应用程序生成调用图，以便您可以查看调用了哪些函数以及它们的调用者。

这显然是对页面其他地方提到的静态方法的补充，它只会有助于消除完全未使用的类、方法和函数——它并不能帮助找到实际调用的方法内的死代码。

Answer 11

我真的没有使用过任何工具来做这样的事情......但是，据我在所有答案中看到的，没有人说过这个问题是不可计算的。

我这是什么意思？这个问题无法通过计算机上的任何算法来解决。这个定理（这样的算法不存在）是图灵停止问题的推论。

您将使用的所有工具都不是算法，而是启发式（即不是精确算法）。他们不会为您提供所有未使用的代码。

Answer 12

一种方法是使用调试器和编译器功能来消除编译期间未使用的机器代码。

一旦消除了某些机器代码，调试器将不允许您在相应的源代码行上放置断点。因此，您在各处放置断点并启动程序并检查断点 - 那些处于“没有为此源加载代码”状态的断点对应于已删除的代码 - 要么该代码从未被调用，要么已被内联，并且您必须执行一些最小的操作分析以确定这两者中哪一个发生了。

至少 Visual Studio 中是这样工作的，我想其他工具集也可以做到这一点。

这是很多工作，但我想比手动分析所有代码更快。

Answer 13

CppDepend 是一个商业工具，可以检测未使用的类型、方法和字段，以及执行更多操作。它适用于 Windows 和 Linux（但目前不支持 64 位），并提供 2 周的试用期。

免责声明：我不在那里工作，但我拥有此工具的许可证（以及 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] }

Answer 14

这取决于您用来创建应用程序的平台。

例如，如果您使用 Visual Studio，则可以使用类似 .NET ANTS Profiler 能够解析和分析您的代码。这样，您应该很快就知道实际使用了代码的哪一部分。 Eclipse 也有等效的插件。

否则，如果您需要知道最终用户实际使用了应用程序的哪些功能，并且如果您可以轻松发布应用程序，则可以使用日志文件进行审核。

对于每个主要功能，您可以跟踪其使用情况，几天/一周后即可获取该日志文件并查看它。

Answer 15

我今天有一个朋友问了我这个问题，我环顾了一些有前途的 Clang 开发，例如 ASTMatcher 和 静态分析器 在编译过程中可能有足够的可见性确定死代码部分，但后来我发现了这个：

https://blog.flameeyes.eu/2008/01/today-how-to-identify-unused-exported-functions-and-variables

这几乎是如何使用的完整描述一些 GCC 标志似乎是为了识别未引用的符号而设计的！

Answer 16

我不认为这可以自动完成。

即使使用代码覆盖工具，您也需要提供足够的输入数据才能运行。

可能是非常复杂且价格昂贵的静态分析工具，例如来自 Coverity 或 LLVM 编译器 可能会有所帮助。

但我不确定，我更喜欢手动代码审查。

更新

嗯..只删除未使用的变量，未使用的函数并不难。

更新

在阅读其他答案和评论后，我更加坚信这是不可能完成的。

您必须了解代码才能进行有意义的代码覆盖率测量，并且如果您知道大量手动编辑将比准备/运行/审查覆盖率结果更快。

Answer 17

GNU 链接器有一个 --cref 选项，可以生成交叉引用信息。您可以通过 -Wl,--cref 从 gcc 命令行传递此信息。

例如，假设 foo.o 定义了一个符号 foo_sym，该符号也在 bar.o 中使用。然后在输出中您将看到：

foo_sym                            foo.o
                                   bar.o

如果 foo_sym 仅限于 foo.o，那么您将看不到任何其他目标文件；它后面会跟着另一个符号：

foo_sym                            foo.o
force_flag                         options.o

现在，我们不知道 foo_sym 没有被使用。它只是一个候选者：我们知道它是在一个文件中定义的，并且没有在任何其他文件中使用。 foo_sym 可以在 foo.o 中定义并在那里使用。

因此，您对这些信息所做的就是

1. 进行一些文本修改，以识别仅限于一个目标文件的这些符号，从而生成候选列表。
2. 进入源代码，并为每个候选人提供静态的内部链接，就像它应该有的那样。
3. 重新编译源码。
4. 现在，对于任何真正未使用的符号，编译器将能够发出警告，为您精确定位它们；你可以删除那些。

当然，我忽略了其中一些符号故意未使用的可能性，因为它们是为了动态链接而导出的（即使链接了可执行文件也可能是这种情况）；这是一个更微妙的情况，您必须了解并明智地处理。

Answer 18

如果你使用 g++，你可以使用这个标志 -Wunused

根据文档：

Warn whenever a variable is unused aside from its declaration, whenever a function is declared static but never defined, whenever a label is declared but not used, and whenever a statement computes a result that is explicitly not used.

http: //docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

编辑：这是其他有用的标志 -Wunreachable-code 根据文档：

This option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.

Answer 19

是否会调用某个函数的一般问题是无法确定的。您无法以一般方式提前知道是否会调用某个函数，因为您不知道图灵机是否会停止。如果有一些路径（静态地）从 main() 到您编写的函数，您可以得到，但这并不能保证它会被调用。如果采用通用形式，则决定是否调用该函数的决策集是不可判定的。

函数可以被其他模块引用，并且可以从 main() 访问（这使得函数可访问），但这不会使其自动调用。这意味着您可以决定该函数是否实际上会被调用（这是问题的不可判定部分），而无需执行它。该问题类似于通过对角线方法创建的图灵机，仅当函数（如程序中定义的）被分类为不可调用时，才执行实际调用该函数的所有函数。我们可以构建这样一个函数，使程序永远不会因结果而停止，从而使问题无法判定......在这种情况下会调用该函数吗？恐怕你不能说。