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.
Related
I try to run codes like
#include <string>
#include <iostream>
int main() {
std::string str = "This is a string";
std::cout << str.starts_with("name");
}
But intellisense will give out an error
"std::__cxx11::basic_string<char, std::char_traits,
std::allocator>" has no member "starts_with" C/C++(135) [6,9]
And It still can be build and produce a correct result.
Also it can find implementation in header file.
But the macro __cplusplus is defined as 201703L
I've already added a command -std=c++20 when building, why this happened?
Compiler: minGW 11.2 compiled by msys2
Assuming you are using Microsoft's C/C++ extension, you must configure the extension to use C++ 20 standard for intellisense.
The easiest way to do this is to add the line "C_Cpp.default.cppStandard": "c++20" to your settings.json file. You can also find the setting in the GUI under the name "Cpp Standard". Selecting c++20 from its dropdown will achieve the same result.
Note that this setting is, by default, set as a global user defaults. You can configure it per-workspace by selecting the Workspace tab in the settings GUI and changing that Cpp Standard dropdown to c++20.
As for why adding the -std=c++20 flag didn't work: -std=c++20 just tells your compiler which standard to use to build your code. 'Intellisense' does not receive this flag because it is a separate tool from the compiler and is therefore not required to support all the standards the compiler supports. It may support less even, although Intellisense tools usually support as current a standard as possible. Therefore the language standard for Intellisense must be configured separately from the compiler (in this case).
Final Note: After changing the setting, try closing and re-opening VS Code. In my experience changing the language standard setting can cause some weirdness to happen. Closing and re-opening VS Code seems to ensure the setting changes take full effect.
Within my bazel.rc file for the C++ Bazel build options, I have specified:
'build --cxxopt="-std=c++1y"'
When I try to change to build --cxxopt="-std=c++14", bazel Throws error of :
''build --cxxopt="-std=c++14"' is not an option'
, with a cursor below 4 in c++14. If I change the 4 to y (c++1y), it compiles with no problem. I tried adding 'std:make_unique' in my code (c++14 addition) , and it clearly does not compile (make _unique is not part of std) which is assume is complaining that c++14 is not set as the standard, hence no make_unique for me.
What is the latest supported version of C++ in bazel? More specifically, how do I enable C++14 / C++17 (and even C++2x) for Bazel build, it those are supported? Thanks!
NOTE: this is not the same as How to set C++ standard version when build with Bazel??. (I am not asking about cpp 11 and I am asking about a very specific toolchain -- GCC/g++) I am not using any of the tools suggested by that thread. I am using GCC / g++ and am restricted in not being able to use the tools suggested by the answer in the previous question, I've RTFMd and googled. Thanks in advance.
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?.
--EDIT
If you would like to use MinGW GCC 8.4.1 and threads/mutex/futures/atomics do not download the Win32 threader version insted download the Posix version.
--EDIT
My installation of MinGW is as follows:
x32-4.8.1-release-win32 (as the threader) - sjlj rev 5
I have unpacked and correctly confirmed that MinGW GCC 4.8.1 (revision 5) is installed in C:\MinGW\mingw32. I have set up Code Blocks to look for the latest and greatest compiler in the correct path (this I am sure of). I can compile a normal program using #include iostream. Ok now when I try and run a program using #include thread it gives me "error: 'thread' is not a member of 'std'".
Now here is what I have done and what I have tried:
I am following a sort of template or tutorial here at cplusplus.com.
I have the code exactly as it is presented on the webpage (towards the bottom).
I have tried, in Code Blocks, to use Compiler flags "Have g++ follow the C++11 ISO language standard -std=c++11".
I have also tried the flag "Have g++ follow the coming C++0x ISO language standard -std=c++0x"
I have tried both at the same time and one at a time, no mas.
I have also tried those commands manually.
Another command I tried manually was -std=gnu++11 which was recommended in the thread header.
--EDIT
It seems like __cplusplus is < 201103L which is stated (or rather defined) in the thread header.
This only happens when I manually use -std=c++11, for some reason C::B removes it if it was manually stated so I must use a check box to use this flag...
--EDIT
My compiler settings under the Toolchain Executables tab are as follows:
C compiler: i686-w64-mingw32-gcc-4.8.1.exe
C++ compiler: i686-w64-mingw32-c++.exe
Linker for dynamic: i686-w64-mingw32-c++.exe
Linker for static: ar.exe
Debbuger: GDB/CDB debugger: default
Resource compiler: windres.exe
Make Program: mingw32-make.exe
I have tried using other executables in the bin folder and still no luck...
I'm starting to wonder if GCC supports C++11 or threading !?
Has anyone been able to get threads to work with MinGW GCC, Code blocks or in general?
If so how did you do it? Any links that might help? Any advice?
P.S. I know there are other ways of threading like posix or other SDK's like SFML (I have successfully tried threading with this). But I want to use GCC threading and I'm quite baffled as to why it is so hard to do seeing as all the necessary files are there...
--EDIT
I have found that when I manually compile the program outside of Code Blocks I still get the same errors, whether I use g++ c++ or i686-w64-mingw32-g++/c++
here is the command I run to build the files:
C:\MinGW\mingw32\bin>g++.exe -D__GXX_EXPERIMENTAL_CXX0X__ -o0 -g3
-Wall -c -fmes sage-length=0 -std=c++11 -Wc++11-compat -o obj\Debug\main.o "F:\C Projects\Code Blocks\thread\main.cpp"
still returns error: 'thread' is not a member of 'std'
Could this be a bad build? I will try other revisions...
--EDIT
probably to late for an answere, but here is what worked for me:
1. Get x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-experimental-stdthread/
2. Setup a new compiler in codeblocks with
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
3. Set the new compiler for your project
Right click in your project -> build options
Select the new compiler
Under compiler falgs check -std=c++0x and -std=c++11
Under Other options set -std=gnu++11
4. Have fun with c++11 concurrency
Hope that works for you also, as an alternative you can just use visual studio.
I think you meant GCC 4.8.1 - the answer is yes, it supports a set of C++11 features including partial multi-threading support. Please visit http://gcc.gnu.org/releases.html to see supported set.
gcc 4.8.1 is C++11 feature complete. I cannot speak to the Windows implementation but certainly on Linux and OS X it works as advertised, including all the concurrency functionality. I just #include <thread> and call g++ -std=gnu++11 and it works. Here's a minimal piece of code that compiles just fine:
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mx;
int i;
void thrfunc();
int main(void)
{
i=0;
std::thread thr1(thrfunc),thr2(thrfunc);
thr1.join();
thr2.join();
return 0;
}
void thrfunc()
{
mx.lock();
i++;
std::cout << std::this_thread::get_id() << " i: " << i << std::endl;
mx.unlock();
}
I had the same issues, I installed the lates MinGW-Builds
http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/
and set my toolchain executables to:
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
I hope this helps.