When using CDT 8.2 in Eclipse (tried Juno as well as Kepler), I cannot get the indexer to recognise code that uses C++11 standard library features, i.e. classes such as std::array, std::unique_ptr, std::shared_ptr, etc. do not get recognised and are therefore underlined with red squiggles. Same for any class that uses one of these new elements, with the effect that the majority of my code gets underlined in red.

The main culprit *seems to be* that the indexer get a wrong value for the __cplusplus macro; it is 199711L instead of the required 201103L. See the attached picture of an excerpt of the GCC <memory> header.
However, I do not know how to tell Eclipse/CDT how to set the correct value for the __cplusplus macro.
I have already done the following:
- The Discovery, Builtin compiler options include '-std=c++11'.
- The compiler options include '-std=c++11'.
- The preprocessor macro __GXX_EXPERIMENTAL_CXX0X__ is set.
See also the other attached pictures.
This pretty much corresponds to the advice given in the CDT FAQ.
The allocated console w.r.t. to the discovery options clearly states the *correct* value for __cplusplus. The log output contains:

Well, it is saying "__cplusplus=201103L" there, and also if I view the console output w.r.t. discovery options (which is probably the same thing).
That's why it's extremely puzzling to see the indexer preprocess the source code wrongly, as shown in the _code_memory.png image attached above.

What can I do to fix this? I have squiggles all over my source code of several large projects, and it doesn't look pretty.

(Side note: I have to say that setting up Eclipse/CDT for proper C++ support has always been quite a pain so far... this should work out of the box or be more intuitive.)

Thanks for the pointer about setting up a new workspace! I seem to have fixed most of the issues that I've had with the indexing.

This is going to be quite a rant, since I find the user experience in setting this up unacceptable. In case any developers are reading this, please pay good attention...

Since I had to set up a new workspace, I had to re-do all the steps to just get Eclipse/CDT to recognise my compiler correctly. It is painful, and so far I've lost half a day to stupid trial-and-error (not the first time this has happened with Eclipse/CDT):

I'm using GCC 4.8.1 on a Mac via MacPorts. Without manually changing the PATH variable in the global environment settings it will only recognise the Apple GCC compiler (an ancient 4.2.1, present by default on the system). And it's more difficult than just changing it to "/opt/local/bin:$PATH" - for some reason, it won't recognise that and all paths have to be spelled out explicitly(!). That's not very intuitive.

Even then, the indexer will *mostly* see the GCC 4.2.1 include files for the standard library. I'm saying mostly, because it will pick up the correct path for files that don't exist in the 4.2.1 include location yet (C++11-only stuff such as type_traits). Needless to say, the indexer doesn't like that.

In order to fix this I have to add the GCC 4.8 standard library directories as the topmost include paths to *all* my projects, as follows:
1) /opt/local/include/gcc48/c++/x86_64-apple-darwin12/
2) /opt/local/include/gcc48/c++/

This has to be done using both these paths in exactly this order, otherwise indexing will fail in strange ways. (For example: If I remove the first include directory, following <type_traits> gets me to the correct include, but the included <bits/c++config.h> inside type_traits will be from GCC 4.2.1. Good luck figuring stuff like that out.)

Of course I also have to add "-std=c++11" in obscure places. Who in his right mind would get the idea to look under the hidden 'Discovery' tab to add this to the built-in compiler options? The fact that this is mentioned in the FAQ doesn't make it any better.

With all this set up, the indexer *still* cannot deal with all my code. I'm pretty sure all issues related to include directories are fixed, and what remains are actual indexer bugs. For example, it chokes on this simple case:

Can't this all be a bit more intuitive? Can't there be, say, some setup procedure that just works(TM)?
Something along the lines of "We found the following compilers on your system: 1) ... 2) ... 3) ... . Which one would you like to use?" And then "Do you want to enable C++ 11 features/indexing in your projects? yes/no".
The steps anyone has to go through at the moment to set this up correctly are beyond acceptable. I don't even want to know what the hell will happen when I want to switch to a Clang toolchain at some point...

Nope. Not all solved. Suddenly, in another project, the mouse-over over the __cplusplus definition tells me that it's recognized as '1'. No idea why, and of course the indexer doesn't like that. Every setting looks ok, though, and it's telling me everywhere else (i.e. in the properties) that the macro is 201103L.
Why does this have to be such a bloody mess?

You should change the PATH environment variable in Windows->Preferences->C/C++->Build->Environment.
- click on "Select ..."
- then select PATH and click OK
- then click "Edit.."
- you should insert the path to g++ at the beginning (I guess it is /opt/local/bin)

You can overwrite these global settings per project (if you like).

In Windows->Preferences->C/C++->Build->Settings open the "Discovery" tab
- select GCC-Builtin Compiler Settings (I think in your case it will be called GCC Mac or something linke this. I am not sure.)
- change the command line

${COMMAND} -E -P -v -dD "${INPUTS}"

to

${COMMAND} -std=c++11 -E -P -v -dD "${INPUTS}"

That's it. (Don't forget to select Mac GCC as your toolchain)

It should *not* be necessary to add any include paths manually. The automatic discovery will (should) do it.

Well, I have done those two things already; see my previous posts where I describe this in detail.

For now, I have added '-D__cplusplus=201103L' to the built-in compiler discovery options. It's brute-force, but it does seem to help at least with the __cplusplus definition, which set itself to '1' for no reason (in one project).

I agree that I should not have to manually add include paths. See the part of the scanner discovery console log that I posted above. That should be sufficient for the indexer to "get it".

I'm using GCC 4.8.1 on a Mac via MacPorts. Without manually changing the PATH variable in the global environment settings it will only recognise the Apple GCC compiler (an ancient 4.2.1, present by default on the system).

Quote:

Suddenly, in another project, the mouse-over over the __cplusplus definition tells me that it's recognized as '1'.

I only could guess, but maybe for unknown reasons CDT finds the old Compiler 4.2.1. And older compilers (up to 4.7) sets __cplusplus = 1.

I'm not a Mac-User, but using Windows I always use a Batch-File to start Eclipse. I do this because than I simply can add the Path to the Compiler I want. For example the batch may look like this:

PATH=C:\MinGW32\bin;%PATH%
start eclipse.exe

This adds the path to my GCC-Compiler (C:\MinGW32\bin;) in front of the other search paths and therefore I'm sure that Eclipse/CDT finds this compiler version (and not a other older version which also could be in the search PATH).
The other advantage is, that I must not add the paths to the GCC-Headers manually within the CDT-Settings.

I guess you run into the following bug:
Built-In Settings Provider ignores compiler command from build Settingshttps://bugs.eclipse.org/bugs/show_bug.cgi?id=404912
Scanner discovery uses the old gcc installation.
In Windows->Preferences->C/C++->Build->Settings open the "Discovery" tab. Here you should change ${COMMAND} to /opt/local/bin/gcc (or whereever you have installed GCC 4.8.1).
(btw, use g++ für C++)

I found that you can redefine __cplusplus by adding it to your CDT User Setting Entries (under C/C++ General->Preprocessor Includes...) and then rebuild your c/c++ index. It's a workaround, but it works the first time, every time.

Stumbled across the same problem. I've added "-std=c++11" to the discover command as described by Axel Mueller in post "Thu, 11 July 2013 11:37", but doesn't fix the problem.

I subsequently switched to "Project Properties->C/C++ General->Preprocessor Include Paths..->Providers tab. There, I had to enable "CDT GCC Build-in Compiler Settings [ Shared ]" (was disabled) and moved it to to top of this list. After clicking "Apply" _cplusplus has been updated and the indexer accepted most parts. Rebuilding the index fixed the remaining parts. It seems to work at the moment.

As to me, setting -std=c++11 in the command line for the GCC compiler didn't change a thing. Thanks to hints in earlier posts that pointed me in that direction, I had to explicitly activate "CDT User Settings Entries" provider in project properties > C/C++ General > Preprocessor Include Paths > Providers. After that, on C/C++ Build > Settings > Tool Settings > GCC C++ Compiler > Preprocessor, I defined "__cplusplus=201103L" in "Defined symbols (-D)" and rebuilt the index.
Then, and only then, did the editor remove the greying in memory.h. Only then did it remove the error marker on unique_ptr.

I think the problem could also be with the compiler. The problem arose when I moved to Mingw-w64 (x86_64-4.9.1-win32-seh-rt_v3-rev0) a few days ago. Is there a command to execute in terminal/console that would list the macros that CDT gets from the compiler? (I mean all the entries that are contributed by the "CDT GCC Built-in Compiler Settings" provider) That way, I would confirm that the bad __cplusplus definition comes from the compiler. I've run the command to which Axel recommended to add -std=c++11 but the output doesn't help in that respect.

Thanks to all.
[EDIT] I wanted to understand where the problem comes from. Here's the experiment I ran and its results.

This means that the -std=c++11 argument is the solution to the problem of the wrong value of the macro.

Unfortunately, the "CDT Manged Build Settings Entries" has no configuration to which I can add the argument, at least none that I could find. I have tried everything I could think of (even deleting the .sc and .pdom files) but there's no way I can get the correct value (201103L) to __cplusplus in that set of entries: the value is and remains 199711L. This means that the provider doesn't care about the dialect configured in project properties > C++ > Build > Settings > Tool Settings > GCC C++ Compiler > Dialect.

This problem, in the instance I am facing, boils down to being able to configure the command that CDT Managed Build uses.

Anyway, it is possible to have the indexer see 201103L if the "CDT GCC Built-in" provider comes before CDT Managed. No need to define a user symbol.