Eclipse 3.7 无法解析 C++ 编辑器中的类型

Eclipse 3.7 cannot resolve Types in C++ Editor

提问by Toby

I recently changed from Eclipse 3.6 to Eclipse 3.7 , which I am using for C++ development in Ubuntu 11.04 .

我最近从 Eclipse 3.6 更改为 Eclipse 3.7 ，我将其用于 Ubuntu 11.04 中的 C++ 开发。

With Version 3.6 I had no big troubles, except that I always had some issues with the indexer. Now with Version 3.7 it begins marking unresolved Types as Errors. Since the indexer seems to dislike me even more, my Eclipse apparently doesn't know types like uint16_tor size_t.

使用 3.6 版时，我没有遇到什么大麻烦，只是索引器总是有一些问题。现在在 3.7 版中，它开始将未解析的类型标记为错误。由于索引器似乎更不喜欢我，我的 Eclipse 显然不知道uint16_t或 之类的类型size_t。

In contrary to the displayed errors in the code editor, my compiler has no problems with compiling the code and resolving all symbols and types, so this seems to be a problem of the IDE itself.

与代码编辑器中显示的错误相反，我的编译器在编译代码和解析所有符号和类型方面都没有问题，所以这似乎是IDE本身的问题。

Are there any ways to avoid this behavior, because all the red underlines make my code more and more unreadable...?

有没有办法避免这种行为，因为所有的红色下划线让我的代码越来越不可读......？

Update:

更新：

Okay with some research and the answer from Dennis I found out that I need to add some paths to Project Properties/ C/C++ General/ Paths and Symbols

好的，通过一些研究和丹尼斯的回答，我发现我需要添加一些路径 Project Properties/ C/C++ General/ Paths and Symbols

Since I am building for a PowerPC instead of a I32 target, I can not just add /usr/include. Instead I needed to add

由于我是为 PowerPC 而不是 I32 目标构建，我不能只添加/usr/include. 相反，我需要添加

/usr/powerpc-linux-gnu/libc/usr/include

/usr/powerpc-linux-gnu/libc/usr/include

for all the standard headers (like stdint.h). Also I needed:

对于所有标准标题（如stdint.h）。我还需要：

/usr/lib/gcc/powerpc-linux-gnu/4.5.1/include

/usr/lib/gcc/powerpc-linux-gnu/4.5.1/include

for the stdarg.h.

对于stdarg.h.

Now almost all the errors are gone. The only function which still troubles me is printffrom the header stdio.h. I looked it up and the header file itself lies within the included paths. Still I get an Error which says Function printf could not be resolved. I want to note again, that these are just errors displayed by Eclipse - The compiling itself works fine.

现在几乎所有的错误都消失了。仍然困扰我的唯一功能是printf来自 header stdio.h。我查了一下，头文件本身位于包含的路径中。我仍然收到一个错误，上面写着Function printf could not be resolved。我想再次说明，这些只是 Eclipse 显示的错误 - 编译本身运行良好。

So this actually throws up 3 questions:

所以这实际上引发了 3 个问题：

1. In the project properties the Paths and Symbolssection coheres with the include Paths out of the C++ Build/Settings/C++ Includessection. This means adding/deleting a path in one of those sections directly affects the entry of the others. Since the C++ Includesdirectly coheres with the Compiler I wonder why the compiler can compile correcty ( and finds the headers ) even if they arent passed to him as a path? Is there some kind of standard path GCC uses, which I don't know about?

2. Why doesn't he find printfin eclipse? The headerfile stdio.his included and it also contains the declaration of printf- so why does the Eclipse Code Editor tell me that it can't resolve it?

3. Why are the header files divided so much? I am aware that I need other header files if I am building for another traget (e.g. PowerPC) - But why does the GNU GCC separate those headers in different dirs?

1. 在项目属性中，该Paths and Symbols部分与该部分外的包含路径一致C++ Build/Settings/C++ Includes。这意味着在这些部分之一中添加/删除路径直接影响其他部分的条目。由于C++ Includes直接与编译器一致，我想知道为什么编译器可以正确编译（并找到头文件），即使它们没有作为路径传递给他？是否有某种标准路径 GCC 使用，我不知道？

2. 为什么他没有printf在日食中找到？头文件stdio.h被包含在内，它也包含声明printf- 那么为什么 Eclipse 代码编辑器告诉我它无法解析它呢？

3. 为什么头文件分得这么多？我知道如果我正在为另一个 traget（例如 PowerPC）构建我需要其他头文件 - 但是为什么 GNU GCC 将这些头文件分开在不同的目录中？

回答by Dennis

The red underlines for common types are usually caused by not having your standard library in your include path. Look at your includes for your project... they are in the project properties. Ensure that your C++ includes have an entry that matches the C++ standard libs folders for the compiler you are using.

常见类型的红色下划线通常是由于包含路径中没有标准库引起的。查看您的项目的包含...它们在项目属性中。确保您的 C++ 包含的条目与您正在使用的编译器的 C++ 标准库文件夹相匹配。

回答by fquinner

After hitting this problem and a search revealing two stack overflow questions hitting the same problem, I figured I would submit how I fixed it after it annoyed me enough to actually investigate.

在遇到这个问题并且搜索发现两个堆栈溢出问题遇到了同样的问题后，我想我会在它让我恼火到实际调查之后提交我的修复方法。

I'm running Fedora and annoyingly, it has a stddef.h file in /usr/include/linux.... which is actually empty. So even though I had the compiler's stddef.h in the include path, the indexer was actually parsing this other empty file. So what needed done was:

我正在运行 Fedora，但令人讨厌的是，它在 /usr/include/linux.... 中有一个 stddef.h 文件，它实际上是空的。所以即使我在包含路径中有编译器的 stddef.h，索引器实际上正在解析这个另一个空文件。所以需要做的是：

Prefixyour paths and symbols list with the compiler specific include path (in my case it was /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/) to avoid the other empty stddef.h from being parsed.

使用特定于编译器的包含路径（在我的情况下为 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/）为您的路径和符号列表添加前缀，以避免解析其他空的 stddef.h。

回答by Philipp Doublehammer

I'm using Eclipse (Mars.1 Release 4.5.1, Build id: 20150924-1200) with an ARM compiler (arm-none-eabi, 4.4.1). I had exactly the same problem as you. My former path was:

我正在使用带有 ARM 编译器（arm-none-eabi，4.4.1）的 Eclipse（Mars.1 Release 4.5.1，Build id：20150924-1200）。我和你有完全一样的问题。我以前的路径是：

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi.4.1\include

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi.4.1\include

Then i discovered another include directory (postfix: 'fixed') at the compiler directories:

然后我在编译器目录中发现了另一个包含目录（后缀：'fixed'）：

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi.4.1\include-fixed

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi.4.1\include-fixed

This fixed all my errors concerining type-misdetection (e. g. uint16_t).

这修复了我所有关于类型错误检测的错误（例如 uint16_t）。