|
|
|
|
Re: Helping the indexer [message #1717069 is a reply to message #1717061] |
Wed, 09 December 2015 19:15 |
Thomas Mising name Messages: 9 Registered: January 2010 |
Junior Member |
|
|
I am getting about the same output.
g++ --version provides
g++ (Debian 5.3.1-3) 5.3.1 20151207
As far as I can remember I have compiled everything again after debian unstable switched to new C++ Api.
Will need to look into that again tomorrow ...
compiling no.cpp gives:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-3' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20151207 (Debian 5.3.1-3)
COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -P -imultiarch x86_64-linux-gnu -D_GNU_SOURCE no.cpp -mtune=generic -march=x86-64 -std=c++11 -dD
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/5
/usr/include/x86_64-linux-gnu/c++/5
/usr/include/c++/5/backward
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
#define __STDC__ 1
#define __cplusplus 201103L
|
|
|
Re: Helping the indexer [message #1717124 is a reply to message #1717069] |
Thu, 10 December 2015 07:10 |
David Vavra Messages: 1426 Registered: October 2012 |
Senior Member |
|
|
Well I don't know then.
You could try unchecking the box that selects the global provider and check the box below it to allocate a console view then you should see what Eclipse is actually seeing when it executes the command. Other than that I don't know what would cause it to not accept the output. It may be a bug that you've somehow triggered.
Edit:
My apologies. I take some of this back. I am confusing your post with another post that is having a superficially similar problem. For one, I said you aren't getting any builtin values but I just realized there was nothing in your post that indicated it.
Going back to your original, you had:
'string' is ambiguous '
Candidates are:
'
I get that myself sometimes. I can't tell you precisely why but I think you used string in a way that has more than one interpretation. The compiler may not care but the indexer might. The std::string class has a rather broad interface with coerced types. You may have encountered one of them. An example is string(string x) and string(char * x). The latter can be coerced to string(string). So, which constructor should be used? It's what the explicit keyword is supposed to help resolve.
Maybe we should back up and look at what you were seeing to begin with.
Start with the full error message and the lines of code associated with them.
[Updated on: Thu, 10 December 2015 07:37] Report message to a moderator
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05157 seconds