C++ C++；。如何知道方法/变量的定义位置？或者如何询问编译器？

在我们非常大的框架中，跟踪一个包中的bug，我最终调用了一个函数

这个函数没有在我正在处理的包中定义，对包本身的搜索不会给我任何关于该函数在框架中定义的位置的线索

显然，它是在框架内的另一个包中定义的

我必须知道这个函数到底做什么，所以我想“询问”编译器它是在哪里定义的。。。因为包编译得很好，所以函数必须在某个地方定义！；-）

---

如何做到这一点？

好吧，我的第一次尝试是在您的框架中尝试全局搜索，如下所示：

grep -R "MyMethod" /my/framework/root/path

或者使用快速和简单的方法

其次，您可以在可执行文件或库上尝试nm：

nm -al myexe

如果使用调试选项编译，则

-l

选项应提供文件和行号

---

my2c

我会在调用“unknown”函数时设置一个断点，然后运行调试器。当调试器在这一点停止时，我将进入函数并打印回溯。然后，它应该进入函数并为您提供函数所在的源文件的信息

使用gcc/gdb，您可以如下方式运行应用程序：

gdb ./path_to_your_app/app_binary (gdb) break SourceWhereYourFunctionIsCalled.cpp:123 (gdb) run (gdb) step (gdb) bt gdb./path\u to\u your\u app/app\u binary （gdb）中断调用函数的源。cpp:123 （gdb）运行 （gdb）步骤 （gdb）英国电信 而使用VisualStudio则更容易。就我记忆所及，只需设置一个断点并使用F10进入。然后源文件将自动打开

---

我假设您有一个调试版本。

如果您在linux/unix平台上，还可以在二进制文件上运行以下命令：

nm-a-l二进制| grep符号

例如：

$ nm -a -l test | grep main
                 U __libc_start_main@@GLIBC_2.2.5
00000000004004a8 T main /home/mwijekoo/tests/sizeof/test.c:6

---

大多数IDE可以在代码中搜索特定的方法或定义。编译器通常不会这样做。在代码中选择方法后，请尝试上下文菜单。 该函数可以在链接库中定义。在这种情况下，除非进行反编译，否则无法访问代码

我需要知道您使用的编译器和IDE等。

您可以通过创建该函数的第二个定义来“询问”编译器（和/或链接器）在何处定义它

void foo();

void foo() // function you are looking for
{
}

void foo() // second definition to tease the compiler.
{
}

现在编译器将向您投诉并给出提示

main.cpp: In function ‘void foo()’:
main.cpp:7: error: redefinition of ‘void foo()’
main.cpp:3: error: ‘void foo()’ previously defined here

链接器现在会抱怨并给你一个提示

b.cpp:(.text+0x6): multiple definition of `foo()'

现在你知道真正的“foo”是在b.cpp中

但是如果它是在头文件中定义的呢

main.cpp：

#include "secret.h"

void foo() // second definition to tease the compiler.
{
}

秘密h:

void foo() // function you are looking for
{
}

现在，编译器将为您找到它：

main.cpp: In function ‘void foo()’:
main.cpp:3: error: redefinition of ‘void foo()’
secret.h:1: error: ‘void foo()’ previously defined here

---

现在您知道真正的“foo”是秘密定义的。h.

如果您能更详细地描述一下您的开发环境，可能会有所帮助。例如，您使用的是哪种编译器？例如，VisualStudio的上下文菜单中有“go to definition”（转到定义）或类似的措辞，可以将您带到正确的位置，同时考虑预处理器宏等。嗨，Christopher。我使用的是EclipseIDE，但对于这个框架，我们使用了一个分布式的定制编译工具CMT（内部称为gmake）。要将Eclipse与这样一个分布式框架联系起来并不容易。但马丁的“gdb”暗示成功了。谢谢你，马丁！很好的建议！：）很好的把戏！！非常感谢，艾迪！而且，我必须承认，用一种非常简单的方法来发现方法是在哪里定义的+1和接受的答案！：）