Home » Language IDEs » C / C++ IDE (CDT) » C++11 standard library indexing fails, __cplusplus recognized with wrong value(C++11 standard library indexing fails)
C++11 standard library indexing fails, __cplusplus recognized with wrong value [message #1067392] |
Mon, 08 July 2013 13:49 |
Michael Hofmann Messages: 9 Registered: December 2012 |
Junior Member |
|
|
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:
"**** Running scanner discovery: CDT GCC Builtin Compiler Settings ****
g++ -E -P -v -std=c++11 -dD /Users/michael/workspace/.metadata/.pluginsorg.eclipse.cdt.managedbuilder.core/spec.C
[...]
Configured with: ../gcc-4.8.1/configure [...] --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 [...]
[...]
#define __cplusplus 201103L <------------ this is correct
gcc version 4.8.1 (MacPorts gcc48 4.8.1_1)
[...]"
I have already tried to rebuild the entire index several times, to no avail.
How can I make the indexer to see __cplusplus as 201103L, such that my code is indexed correctly?
|
|
| | | |
Re: C++11 standard library indexing fails, __cplusplus recognized with wrong value [message #1067976 is a reply to message #1067825] |
Thu, 11 July 2013 13:56 |
Michael Hofmann Messages: 9 Registered: December 2012 |
Junior Member |
|
|
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.)
It's weird that this mess happens in the first place, since the scanner discovery output *seems* ok, with all the right directories. See part of the log:
14:57:53 **** Running scanner discovery: CDT GCC Built-in Compiler Settings ****
g++ -E -P -v -std=c++11 -dD /Users/michael/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
#define __cplusplus 201103L
(...)
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin12 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_1'
- 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:
#include <type_traits>
constexpr bool BAR() { return true; }
struct Foo
{
void foo(std::enable_if<true>::type* = nullptr) {} // indexer is fine with this
void bar(std::enable_if<BAR()>::type* = nullptr) {} // indexer has issues with that
};
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...
Michael
|
|
| | | | |
Re: C++11 standard library indexing fails, __cplusplus recognized with wrong value [message #1068142 is a reply to message #1067982] |
Fri, 12 July 2013 12:02 |
Klaus km Messages: 142 Registered: November 2011 |
Senior Member |
|
|
Hello Michael,
Quote: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 found this GCC Bugzilla entry about this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
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.
Hope this helps you to find out the problem...
regards,
klaus
CDT User Guide
CDT User FAQ
|
|
| | | |
Re: C++11 standard library indexing fails, __cplusplus recognized with wrong value [message #1270792 is a reply to message #1067392] |
Thu, 13 March 2014 13:52 |
Thread Feuerstein Messages: 1 Registered: March 2014 |
Junior Member |
|
|
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.
Details: Eclipse Kepler 4.3.2, CDT 8.3, CMake[2.8.12, CDT4 Makefile] Out-Of-Source Project, Manjaro 0.8.9, Hotspot JVM 7.0_51
|
|
|
Re: C++11 standard library indexing fails, __cplusplus recognized with wrong value [message #1419224 is a reply to message #1270792] |
Mon, 08 September 2014 09:30 |
Amenel Voglozin Messages: 23 Registered: September 2009 |
Junior Member |
|
|
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.
The command I was looking for is
g++ -E -P -v -std=c++11 -dD <your workspace>\.metadata\.plugins\org.eclipse.cdt.make.core\specs.cpp > options.txt
When I run it with -std=c++11, options.txt has #define __cplusplus 201103L
When I run it without that argument, I get #define __cplusplus 199711L
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.
[Updated on: Mon, 08 September 2014 21:34] Report message to a moderator
|
|
| | | |
Goto Forum:
Current Time: Sat Nov 23 11:06:41 GMT 2024
Powered by FUDForum. Page generated in 0.14749 seconds
|