I am playing with unique_ptr. In my last post people helped me compiling a program that used this pointer by specifying the -std=c++0x during compilation.
Now i was wondering if there is any way to instruct eclipse to consider c++11 while auto-completing?
unique_ptr is not coming in the list of std:: namespace, nor I can find the methods (reset, move...) associated with a unique_ptr.
Thank you
vahid
The "memory" header (probably found at /usr/include/c++/4.9/memory) only includes "unique_ptr.h" and "shared_ptr.h" (probably found at /usr/include/c++/4.9/bits/unique_ptr.h and /usr/include/c++/4.9/bits/shared_ptr.h) if the macro "__cplusplus" is equal or greather than "201103L". Check memory.h for yourself to see the "#if" preprocessor condition there, at line 69 (or search for the string "#if __cplusplus >= 201103L").
As others mentioned, compiling with "-std=c++0x" or later c++ standards (-std=c++11 or -std=c++14) solves the compilation errors, but not the eclipse indexing and autocomplete problem.
To solve the eclipse indexing issue I added the "__cplusplus" Preprocessor Macro to the project build properties, with the value "201103L", and afterwards I refreshed the index;
To add the preprocessor macro:
"right click the project on project explorer" >> properties >> C/C++ General >> Preprocessor Includes >> Entries >> GNU C++ >> CDT User Settings Entries >> Add... >> Preprocessor Macro;
Then entry a macro with name "__cplusplus" and value "201103L";
Afterwards, to refresh the index, do:
"right click project on project explorer" >> Index >> Rebuild;
Ps.: I was using gcc 4.9.2 and eclipse Luna (4.4.2), on ubuntu 15.04 64bits
I guess you should add __GXX_EXPERIMENTAL_CXX0X__ definition to your "Paths and Symbols" in Eclipse. See also this question GNU C++ how to check when -std=c++0x is in effect? and the same question Eclipse indexer can't resolve shared_ptr for shared_ptr.
Related
I've recently updated to Eclipse Mars.2 (version 4.5.2) and switched my project to C++11 development (yeah, it's about time!).
I've managed to configure all my Makefiles to build correctly (ie. no obvious errors or warnings) but the Eclipse built-in indexer reports several false-positive semantic errors. Not all of them have to do with C++11 specific features.
I'm referring to already existing threads [1] and [2] which are older and haven't brought any real solution for me.
False-positives examples
std::next(..) not recognized - but I have no problems with std::begin() or std::end():
std::vector<int> v;
for (auto i = std::begin(v); i != std::end(v); i++)
{
std::next(i);
}
Invalid arguments '
Candidates are:
#0 next(#0, std::iterator_traits<#0>::difference_type)
Semantic Error
std::string::substr(..) not recognized:
std::string myString = "test";
myString.substr(0, 1);
Invalid arguments '
Candidates are:
std::basic_string,std::allocator> substr(?, ?)
Semantic Error
googletest's ASSERT_EQ macro is not not recognized (however, other assertions work!):
std::string expValue = "test";
std::string actValue = "test";
ASSERT_EQ(expValue, actValue);
Function 'Compare' could not be resolved
Semantic Error
I've tested various project settings and I came to the conclusion that it has something to do with the Eclipse project's "Paths and Symbols" settings as well with the "Preprocessor Include Paths, Macros, etc." settings. Especially the order of the Providers is highly sensitive for any changes.
The additional problem is that I have an older system with gcc 4.4.4 compiler (default in /usr/bin/gcc) and an additional gcc 4.8.2 installed in /opt/... which shall be actually used for compilation. This also means that I have two sets of header files but only one includes the C++11 features.
My current configuration is this (as seen in Project Settings -> C/C++ General -> Preprocessor Includes Paths -> Entries):
CDT User Settings Entries
system headers of gcc 4.8.2 (treated as built-in)
preprocessor macro __cplusplus = 201103L
CDT Managed Build Settings Entries
paths to custom includes and library paths
CDT GCC Build Output Parser
CDT GCC Built-in Compiler Settings
non-changeable system headers of gcc 4.4.4
local includes
I have tried other combinations as well but this one gives me lowest amount of false-positive errors.
The indexer has project specific settings enabled. I haven't found any switch so far that makes the errors go away.
Has anybody experienced such problems as well? Is it a configuration issue of my paths and symbols or is it a bug in the Eclipse indexer?
std::next(i); is incorrect. When you use
for (auto i : v)
{
std::next(i);
}
i becomes of the type *(v.begin()) which in your code is an int. std::next requires an iterator and that iterator must also provide a difference_type type.
The whole purpose of a ranged based for loop is to not have to worry about advancing through the container. If you wanted to print everything out of the vector you would just use
for (auto i : v)
{
std::cout << i << " ";
}
I know this doesn't solve your other error but it fixes the first one
I updated Eclipse CDT to version 8.8.1 and the false-positive compile errors don't show up anymore. So after all it was a software bug.
I have written a program using C++11 features.
/* * test.cpp * * Created on: 05-Jul-2015 * Author: avirup */
#include<vector>
#include<iterator>
#include<iostream>
using namespace std;
int main() {
vector<int> v;
v.push_back(5);
v.push_back(7);
for(auto i=v.begin();i!=v.end();i++) {
cout<<*i<<endl;
}
for(auto i=v.cbegin();i!=v.cend();++i) {
cout<<*i<<endl;
}
}
The program is compiling correctly and showing results but the editor is showing but red lines below valid functions like cbegin() and cend() which are constant reference iterators. which is annoying. How to get rid of this?
Just for completeness since this has no answer and give an explanation.
To achieve compiling with C++ 11 (or another version) and Eclipse actually supporting it you need to do two things.
First the compiler flag needs to set so -std=c++11 or -std=c++0x is appended when calling g++ or whatever is used.
Open the properties for the properties for the project. Select it and right click ↦ Properties (or Alt+Enter for Windows users)
Go to C/C++ Build ↦ Settings, maybe select your preferred configuration, ↦ GCC C++ Compiler (or any other compiler you use) ↦ Dialect.
Select from the combo or write the flag to the Other dialect flags if not present in the combo (like -std=gnu++14 or -std=c++1z).
CDT will now call your compiler with -std=c++0x when compiling. Now to the part so CDT supports C++11 and does not show errors for missing types and such. My libstdc++ contains lines like
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else // C++0x
that causes your errors and the actual type declarations/definitions are greyed out if you view them in the C/C++ editor. __cplusplus needs to be set correctly with #define __cplusplus 201103L so they will be parsed and indexed by CDT. This is also done via the project settings or can also be done for the whole workspace.
Go again to the project settings.
C/C++ General ↦ Preprocessor Include Paths, Macros etc., also maybe select your preferred configuration, ↦ tab Providers.
Select the entry for your compiler (for me it’s CDT GCC Built-in Compiler Settings MinGW.
Add -std=c++11 or -std=c++0x to the Command to get compiler specs textfield at any location.
Optional: Select Allocate console in the Console View and hit apply. You should now see something like #define __cplusplus 201103L in the console.
To set it for the whole workspace just check Use global provider shared between projects and click on Workspace Settings where an almost identical dialog opens.
I’m currently writing a plug-in that extends the new C/C++ project wizard where one can select the C++ version for the project that sets the compiler flag correctly and also the above setting for the indexer and some other stuff. But dunno if it will ever will be integrated into CDT or needs to be installed via plug-in. But it sure will be in https://www.cevelop.com in a few months.
When reading the std library implementation I could see lots of checks enabled by #if _LIBCPP_DEBUG_LEVEL >= 2 conditions. I tried to add _LIBCPP_DEBUG_LEVEL = 3 in xcode preprocessor options, but <iterator> doesn't compile anymore:
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__insert_i(this); <----- the error is on this line
#endif
Is there something else I'm missing here to use a higher debug level for the standard library?
According to the libc++ documentation:
Debug mode is currently not functional. Defining _LIBCPP_DEBUG will result in fairly nasty compile errors.
So that is probably the source of that.
Baum mit Augen's answer that _LIBCPP_DEBUG_LEVEL >= 2 standard library code for lower level iterator debugging is basically unusable, appears to still be the case with the out-of-the-box Xcode 11.6. But if you're up for extra work or just want more specifics, read on...
Enabling _LIBCPP_DEBUG_LEVEL code is enabling LLVM's Debug Mode. According to that documentation, enabling this debug mode is done by defining the _LIBCPP_DEBUG to a value of 0 (that "enables most of libc++’s assertions") or 1 (that "enables 'iterator debugging' which provides additional assertions about the validity of iterators used by the program").
In XCode 11.6, I've found that adding _LIBCPP_DEBUG=0 to a project's Debug Preprocessor Macros setting, compiles and links and indeed adds additional checks - at least checking against out of range references to std::vector elements via its [] operator. Enabling the _LIBCPP_DEBUG_LEVEL >= 2 code is done by instead setting _LIBCPP_DEBUG=1. That alone however won't fully link as not all the necessary symbols are found. Specifically, the std::__1::__libcpp_db::__insert_c(void*, std::__1::__c_node* (*)(void*, void*, std::__1::__c_node*)) symbol is reported as undefined and maybe others as well. Presumably, XCode 11.6 did not ship with this built into the standard C++ library it provides. If anybody knows better or could corroborate this, I'd appreciate hearing from them.
With the following extra work, I've been able to enable libc++'s assertions plus the additional iterator debugging capabilities:
Install a recent LLVM package somewhere that doesn't interfere with Xcode's included LLVM package. I installed LLVM 10.0.1 using Homebrew and I was able to access it then under /usr/local/Cellar/llvm/10.0.1.
Have Xcode recognize the Xcode tool chain support that this new LLVM package provides. I added a symbolic link to /usr/local/Cellar/llvm/10.0.1/Toolchains/LLVM10.0.1.xctoolchain into Xcode's /Applications/Xcode.app/Contents/Developer/Toolchains directory. I'd done that while Xcode was running and it immediately saw the new tool chain but I had to restart Xcode to get it to compile with it.
Under Xcode's "Xcode" -> "Toolchains" submenu, select the new tool chain. My setup showed "Xcode 11.7" and "org.llvm.10.0.1" and I selected the latter to accomplish this.
Add the path to the new tool chain's usr/lib directory to the LIBRARY_SEARCH_PATHS declaration for resulting executable Targets. I did this by adding /usr/local/Cellar/llvm/10.0.1/Toolchains/LLVM10.0.1.xctoolchain/usr/lib to a project's executable target "Library Search Paths" "Debug" setting.
Have the path to the new tool chain's include directory override the normal standard library's include directory. I haven't confirmed that this is necessary but did this by adding to my library and executable targets' OTHER_CPLUSPLUSFLAGS declaration the value of -nostdinc++ -I/usr/local/Cellar/llvm/10.0.1/Toolchains/LLVM10.0.1.xctoolchain/usr/include/c++/v1. From within Xcode, I'd achieved that by setting the "Other C++ Flags" setting to include this value for the targets of interest. I suspect it's probably safer to make this change at the project level than target level.
Set the COMPILER_INDEX_STORE_ENABLE declaration to NO. This prevented "Unknown argument: '-index-store-path'" errors that stopped builds right from the beginning. I used Xcode's "Enable Index-While-Building Functionality" setting and set it to "No" for this.
Add _LIBCPP_DEBUG=1 to the GCC_PREPROCESSOR_DEFINITIONS declaration for the project. Did this by adding it to Xcode's "Preprocessor Macros" "Debug" setting.
For related Q&A about this, see Is it possible to enable _LIBCPP_DEBUG2 in the current Xcode 4.6.1 toolchain on Mountain Lion?.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Turn off eclipse errors (that arent really errors)
I'm facing this annoying issue: Eclipse refuses to recognize the std::to_string function, but my program compiles without errors. What am I missing?
According to cppreference the std::to_string function is defined in <string>, so I included it explicitly in the incriminated .cpp file. I also tried this, this and this solutions, with no luck.
Any other suggestions?
EDIT:
I'm using g++ 4.7.2 under Linux.
UPDATE: It's been a long time since I posted the original answer and it has become outdated. I double-checked today (Mar 15, 2014): in Eclipse Kepler (Build id 20130614-0229) it is sufficient to
add under Project > Properties > C/C++ Build > Settings then on the Tool Settings tab GCC C++ Compiler > Miscellaneous the -std=c++11 flag,
then under Window > Preferences > C/C++ > Build > Settings on the Discovery tab chose CDT GCC Built-in Compiler Settings and add the -std=c++11 flag to Command to get compiler specs. On my machine it looks like this after the change:
${COMMAND} -E -P -v -dD -std=c++11 "${INPUTS}"
clean and rebuild both your project and your index (Project > C/C++ Index > Rebuild) as Eclipse tends to cache error messages and show them even though they are gone after changing the settings.
This works on my machine for sure. If it doesn't on yours, then you might want to give a shot to this: C++11 full support on Eclipse although I am neither sure about the correctness of this approach nor was it necessary to do it on my machine. As of March 7, 2014 users claim that it helped them whereas the above approach didn't.
The original post, now outdated:
It seems like you have run into the common problem with Codan, see my answer here.
It isn't 100% clear how the code compiles. Within Eclipse? Or from command line, properly setting the flags? So just in case:
You are using a C++11 function. Do you pass the -std=c++0x or the -std=c++11 flags to the compiler (assuming gcc)?
You might have to also add __GXX_EXPERIMENTAL_CXX0X__ to your defines (again, assuming gcc) and restart Eclipse.
In my case eclipse believes __cplusplus is defined to 199711L but I'm quite certain that this should be defined to something along the lines of 201103L because the libstdc++ v3 uses
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else
in most of the new C++11 headers such as <future> and basic_string.h (where the definition of std::to_string is) which is included by <string>. Although when compiling with g++ (Built by MinGW-builds project) 4.8.0 20121225 (experimental) I get absolutely no error. This strange behaviour apparently confuses eclipse and makes it fail to properly phrase the included files.
Defining __cplusplus to something over 201103L before including the C++11 files should fix the bogus eclipse syntax errors such as Symbol 'shared_ptr' could not be resolved.
#undef __cplusplus
#define __cplusplus 201900L
After making the redefinition you'll want to right click on the project Index -> Rebuild & Freshen all files or even better restart eclipse all together.
Not sure what to make of this error. Added -D_WIN32_WINNT=0x0501 to Visual Studio's "Command Line" options under Project Properties but it says it doesn't recognize it and the warning still appears.
I am also not sure how to add the Preprocessor Definition.
1>Please define _WIN32_WINNT or
_WIN32_WINDOWS appropriately. For example:
1>- add -D_WIN32_WINNT=0x0501
to the compiler command line; or
1>-
add _WIN32_WINNT=0x0501 to your
project's Preprocessor Definitions.
Add following line in your top source code.
#include <SDKDDKVer.h>
I think you're really close to getting this to work. John Dibling gave three ways you could do this and it looks like you tried the third solution, which was to "go in to your project's settings ... and under the Configuration Properties->C/C++->PreProcessor heading, add ;_WIN32_WINNT = 0x0501". You replied that you were still getting that error and provided the contents of your preprocessor settings, WIN32;_DEBUG;_CONSOLE;_WIN32_WINNT = 0x0501. I think you can solve this if you change _WIN32_WINNT = 0x0501 to _WIN32_WINNT=0x0501. When I tried the version with spaces, it did not eliminate the error, but removing the spaces did.
A few options.
1) If you have a main header file, like stdafx.h, you could add this:
#define _WIN32_WINNT 0x0501
Or you could add that anywhere you need it.
2) You can add -D _WIN32_WINNT=0x0501 (note the space)
3) Go to Project Properties > Configuration Properties > C/C++ > Proporcessor. Add ;_WIN32_WINNT=0x0501 to Preprocessor Definitions.
Personally, I choose #3 because there's no doubt about it being defined at the right time in the right translation units, and I'd rather have all the #defines in one place rather than some being in Preprocessor Defines and others in the advanced tab.
Put a space after the D
You should define the WIndow sversion you ant to target as many have suggested:
// Target Windows XP
#define _WIN32_WINNT 0x0501
The reasons you do not want to use the SDK version that happens to be installed are:
To have reproducible builds. You don't want to just pick up whatever happens to be installed as that can very for each person trying to build.
To be in control of your target platform. You don't want to target Windows 11 just because you happen to compile on Windows 11. As the programmer, you want to be in control of what is done.
To support the widest range of Windows versions. Users will be grateful that they can run your program on their older Windows version.
For Code Blocks here is how you do it.
Right click **Project Name** on your left >> Click 'Build Options' >> Select Debug or Release on your left >> Select 'Compiler Settings' Tab on the right >> Select #defines tab >> Then add the following line as it is:
_WIN32_WINNT=0x0501
>> Click Ok >> Close >> Right click **Project Name** again >> Re-build.
OP didn't ask about CMake, but google brought me here. If you're using CMake, try adding this to your (top-level) CMakeLists.txt:
if (WIN32)
add_definitions(-D_WIN32_WINNT=<myWindowsTarget>
endif()
I was interested in Windows 10, so myWindowsTarget was 0x0A00. Here's a full list of Windows Targets