I've just started using Eclipse Indigo (coming from Galileo) and I'm getting little red bugs in the gutter for every use of size_t.
The code compiles without issue but I suspect I have to explicitly add a path to the include directories. I already have the usual suspects in there. I am cross compiling for a ColdFire processor using the Gnu tool chain so in addition to the standard include from mfg of the chip I have the includes under m68k-elf
\include
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf
I noticed that the only place stddef.h exists for this toolchain is in a lib
directory
gcc-m68k\lib\gcc\m68k-elf\4.2.1\include
I added that path, the parent path and \include-fixed
from the parent but the problem still exists.
When testing what works and what doesn't I noticed a couple of things
Symbol is not resolved
will not make the error go away. Syntax and Semantic Errors
, triggering the analysis, going back in and turning them all back on and then turning off Symbol is not resolved
keeps the error from reappearing. size_t is a base unsigned integer memsize-type defined in the standard library of C/C++ languages. This type is described in the header file stddef.
std::size_t is defined in <cstddef> .
Yes, size_t is guaranteed to be an unsigned type.
So we cannot use them interchangeably. One standard recommendation is that the size_t be at most as big as an unsigned long. So you may think that we can use unsigned long in the place of size_t, but unsigned long on 64-bit system, if the OS ins Windows, will be of 32-bits, but size_t will be of 64-bits.
Check your indexer settings under Preferences -> C/C++ -> Indexer.
There is a field there called "Filed to index up-front". Its contents should be:
cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio
If there is something else in there, try replacing it with the above, then rebuild the index, and see if that fixes the problem.
(In particular, if what you have in that field is stdarg.h, stddef.h, sys/types.h
, then I have a pretty good guess as to what went wrong. Back in Eclipse Ganymede, the value of this field was stdarg.h, stddef.h, sys/types.h
. In newer versions (Galileo and Indigo), it was changed to the above. However, since this field is part of "preferences", if you exported your Ganymede preferences and imported them into Galileo/Indigo, this field was overwritten with the old Ganymede value. I was burned by this a while ago.)
To make sure to get size_t
you should #include
the header <cstddef>
; then, it would be std::size_t
, unless you also put a using namespace std
or a using std::size_t
.
If your toolchain can compile the code with only its default include paths and symbols, just setting Eclipse to use them should be enough. Go to C/C++ Build -> Discovery Options
in the project properties, and for each language, change the Compiler invocation command
from the native compiler (e.g. g++
) to your cross compiler (e.g. C:\nburn\gcc-m68k\bin\g++
perhaps?). Then on the next build, the auto-discovery will run and update the so-called "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols
to whatever your compiler reported, and you can re-index again to make sure any warnings for the old "built-ins" are gone.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With