11

我刚刚开始使用 Eclipse Indigo(来自 Galileo),每次使用 size_t 时,我都会在排水沟中发现小红虫。

在此处输入图像描述

代码编译没有问题,但我怀疑我必须明确添加包含目录的路径。我已经有通常的嫌疑人在那里了。我正在使用 Gnu 工具链为 ColdFire 处理器进行交叉编译,因此除了来自芯片制造商的标准包含之外,我还拥有 m68k-elf 下的包含

\include  
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf

更新

我注意到这个工具链的唯一位置 stddef.h 是在一个lib目录中

gcc-m68k\lib\gcc\m68k-elf\4.2.1\include

我添加了该路径,父路径和\include-fixed来自父路径,但问题仍然存在。

测试注意事项

在测试什么有效,什么无效时,我注意到了几件事

  1. 修改代码分析首选项设置时不会重新触发代码分析,我仍然需要更改编辑器(只需添加空格即可)
  2. 关闭代码分析设置Symbol is not resolved不会使错误消失。
  3. 关闭所有Syntax and Semantic Errors,触发分析,返回并重新打开它们,然后关闭Symbol is not resolved可以防止错误再次出现。
4

5 回答 5

3

检查首选项 -> C/C++ -> 索引器下的索引器设置。

那里有一个名为“预先归档以索引”的字段。它的内容应该是:

cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio

如果其中还有其他内容,请尝试将其替换为上述内容,然后重建索引,看看是否能解决问题。

(特别是,如果您在该字段中的值是stdarg.h, stddef.h, sys/types.h,那么我可以很好地猜测出了什么问题。回到 Eclipse Ganymede 中,该字段的值是stdarg.h, stddef.h, sys/types.h。在较新的版本(Galileo 和 Indigo)中,它已更改到上面。但是,由于该字段是“首选项”的一部分,如果您导出您的 Ganymede 首选项并将它们导入到 Galileo/Indigo,该字段将被旧的 Ganymede 值覆盖。我前一阵子被这个烧毁了。)

于 2012-04-10T20:06:11.207 回答
2

为了确保得到size_t你应该#include的标题<cstddef>;那么,它会是std::size_t,除非你也放了 ausing namespace std或 a using std::size_t

于 2012-04-10T19:43:48.047 回答
1

如果您的工具链可以仅使用其默认包含路径和符号编译代码,那么只需将 Eclipse 设置为使用它们就足够了。转到C/C++ Build -> Discovery Options项目属性中,对于每种语言,Compiler invocation command将本地编译器(例如g++)更改为您的交叉编译器(例如,C:\nburn\gcc-m68k\bin\g++也许?)。然后在下一次构建中,自动发现将运行并将项目中显示的所谓“内置”路径和符号更新为C/C++ General -> Paths and Symbols编译器报告的任何内容,您可以再次重新索引以确保任何警告因为旧的“内置”已经消失了。

于 2012-11-23T07:29:48.153 回答
1

在遇到这个问题并且搜索显示两个堆栈溢出问题遇到相同的问题之后,我想我会提交我如何修复它,因为它让我非常恼火以至于无法进行实际调查。

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

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

于 2013-06-24T17:41:33.260 回答
0

我实际上有同样的问题。这个问题似乎与 fquinner 的帖子中描述的问题相同,位于其中的 stddef.h/usr/include/linux/stddef.h也是空的。奇怪的stddef.h是,eclipse找到了正确的,甚至可以毫无问题地打开。

如果您只需要像我一样通过 eclipse 修复索引(例如在使用另一个构建工具构建时),可以通过定义__SIZE_TYPE__预期类型来解决这个索引问题,例如long unsigned intC/C++ General -> Paths and Symbols.

于 2017-06-07T10:05:16.227 回答