If you are on Linux, you may want to look into callgrind, a C/C++ program analysis tool that is part of the valgrind suite, which also contains tools that check for memory leaks and other memory errors (which you should be using as well). It analyzes a running instance of your program, and produces data about its call graph, and about the performance costs of nodes on the call graph. It is usually used for performance analysis, but it also produces a call graph for your applications, so you can see what functions are called, as well as their callers.

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

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

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

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

我自己没有使用过cppcheck，但它声称可以找到未使用的函数。这也许不能完全解决问题，但可能是个开始。

我通常找没用的东西的方法是

确保构建系统正确地处理依赖项跟踪 设置第二个监视器，使用全屏终端窗口，运行重复构建并显示第一个满屏的输出。watch "make 2>&1"倾向于在Unix上做到这一点。 在整个源代码树上运行查找和替换操作，添加“//?”“在每一行的开头 通过删除相应行中的"//?"来修复编译器标记的第一个错误。 重复操作，直到没有错误。

这是一个有点漫长的过程，但确实能得到很好的结果。

对于未使用的整个函数(和未使用的全局变量)，GCC实际上可以为您完成大部分工作，前提是您使用GCC和GNU ld。

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

(当然，你也可以跳过——print-gc-sections部分，让链接器无声地删除函数，但将它们保留在源代码中。)

注意:这只会发现未使用的完整函数，它不会对函数中的死代码做任何事情。在活函数中从死代码调用的函数也将被保留。

一些c++特有的特性也会导致问题，特别是:

Virtual functions. Without knowing which subclasses exist and which are actually instantiated at run time, you can't know which virtual functions you need to exist in the final program. The linker doesn't have enough information about that so it will have to keep all of them around. Globals with constructors, and their constructors. In general, the linker can't know that the constructor for a global doesn't have side effects, so it must run it. Obviously this means the global itself also needs to be kept.

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

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

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和用于那里。

那么，你该怎么处理这些信息呢

执行一些文本修改，以识别限制在一个目标文件中的这些符号，生成候选列表。 进入源代码，给每个候选对象提供带有静态的内部链接，就像它应该有的那样。 重新编译源代码。 现在，对于那些真正未使用的符号，编译器将能够警告，为你精确定位它们;你可以删除它们。

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