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

这是什么意思呢?这个问题不能用计算机上的任何算法解决。这个定理(这样的算法不存在)是图灵停止问题的一个推论。

你将使用的所有工具都不是算法，而是启发式(即不是精确的算法)。他们不会给你所有没有使用的代码。

我认为您正在寻找一个代码覆盖工具。代码覆盖工具将在代码运行时分析它，它将让您知道哪些代码行被执行了，执行了多少次，以及哪些代码没有执行。

您可以尝试使用这个开源代码覆盖工具:TestCocoon—用于C/ c++和c#的代码覆盖工具。

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] }

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

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

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

真正的答案是:你永远无法真正确定。

至少，对于重要的情况，你不能确定你已经得到了全部。考虑以下来自维基百科关于不可达代码的文章:

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

正如维基百科正确指出的那样，一个聪明的编译器也许能够捕捉到这样的东西。但是考虑一下修改:

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

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

Will the compiler catch this? Maybe. But to do that, it will need to do more than run sqrt against a constant scalar value. It will have to figure out that (double)y will always be an integer (easy), and then understand the mathematical range of sqrt for the set of integers (hard). A very sophisticated compiler might be able to do this for the sqrt function, or for every function in math.h, or for any fixed-input function whose domain it can figure out. This gets very, very complex, and the complexity is basically limitless. You can keep adding layers of sophistication to your compiler, but there will always be a way to sneak in some code that will be unreachable for any given set of inputs.

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

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

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

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

根据文档:

每当变量未使用时发出警告 除了它的声明，无论何时 函数被声明为静态的，但是 从来没有定义，每当一个标签 声明但未使用，并且每当a 语句计算的结果为 明确没有使用。

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

编辑:这里是另一个有用的标志-Wunreachable-code 根据文档:

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

更新:我在遗留的C/ c++项目中发现了类似的主题死代码检测