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

Eclipse 3.7 cannot resolve Types in C++ Editor

本文关键字：编辑器 类型 C++ Eclipse      更新时间：2023-10-16

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

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

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

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

更新：

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

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

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

用于所有标准报头（如stdint.h）。我还需要：

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

对于CCD_ 8。

现在几乎所有的错误都消失了。唯一仍然困扰我的函数是来自标头stdio.h的printf。我查了一下，头文件本身就在包含的路径中。我仍然得到一个错误，上面写着Function printf could not be resolved。我想再次指出，这些只是Eclipse显示的错误——编译本身运行良好。

因此，这实际上提出了3个问题：

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

  2. 为什么他没有在eclipse中找到printf？包括头文件stdio.h，它还包含printf的声明——那么为什么Eclipse代码编辑器告诉我它不能解决它呢？

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

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

在遇到这个问题，并且搜索显示两个堆栈溢出问题遇到了同一个问题后，我想我会提交我是如何解决的，因为它让我非常恼火，以至于我可以进行实际调查。

我正在运行Fedora，令人恼火的是，它在/usr/include/linux中有一个stddef.h文件。。。。它实际上是空的。因此，尽管我在include路径中有编译器的stddef.h，但索引器实际上是在解析另一个空文件。所以需要做的是：

用编译器特定的include路径（在我的例子中是/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/）作为路径和符号列表的前缀，以避免解析其他空的stddef.h。

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

D:testCodeSourcerySourcery G++ Litelibgccarm-none-eabi4.4.1include

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

D:testCodeSourcerySourcery G++ Litelibgccarm-none-eabi4.4.1include-fixed

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

相关文章：