I want to use std::source_location in Qt Creator, I've built the GCC 11.1 and checked it using g++ main.cpp -std=c++20 that it works. I've created a kit in Qt Creator to use this compiler and I was able to build it by adding:
QMAKE_CXXFLAGS += -std=c++2a
It works and I can even debug it without issues but Qt keeps saying that I have an error (which is not an error because the build passes):
error: no type named 'source_location' in namespace 'std'
Is there something I can do to fix this?
It's all about clang's static analysis. The gcc's (or strictly libstdc++'s) header <source_location> contains following guard:
#if __cplusplus > 201703L && __has_builtin(__builtin_source_location)
The guard doesn't allow clang to work as it doesn't support __builtin_source_location. Please follow the clang PR that fixes this issue.
Related
How can I enable C++14 support in QtCreator 3.3 using Clang 3.5? I have added a Clang kit and I have added CONFIG += c++14 in my project file. However when using e.g. return type deduction I get the following error:
error: 'auto' return without trailing return type; deduced return types are a C++1y extension
you can use CONFIG += c++14 in .pro file with Qt5.5
but there is a bug with clang, so we need to modify the Qt/5.5/clang_64/mkspecs/features/c++14.prf file,
add this code beforeinclude(c++11.prf) :
contains(QMAKE_LFLAGS_CXX11, -stdlib=libc++) {
QMAKE_CXXFLAGS_CXX11 += -stdlib=libc++
}
I had to go to the Makefile in the build folder and manually replace -std=c++11 with -std=c++14.
Thankfully the Makefile is only written once when you add the kit to the project. I only had to do this once and could build in QtCreator as often as I want.
So now I can use a Clang kit to use all the new c++14 features. As a bonus, I can also use all the c++17 features if I manually set -std=c++1z in the Makefile. Sweet!
I'm currently using C++11 features in my Qt applications. However, I'd like to use some of the new C++14 features in my applications.
To enable C++11 in a Qt application, one only needs to add one line in the qmake project file, namely:
CONFIG += c++11
or this for earlier versions:
QMAKE_CXXFLAGS += -std=c++1y
I already tried to do the same with C++14, but it didn't work. I changed the above mentioned line of the qmake project like this:
CONFIG += c++14
or this for earlier versions:
QMAKE_CXXFLAGS += -std=c++1y
After that, lots of compilation errors, that did not exist before, appear when trying to build the project. The project compiles fine, however, if I try to use any C++14 features, I get a compilation error. This is an example:
template<typename T>
constexpr T pi = T(3.1415926535897932385);
This is the corresponding error:
main.cpp:7: error: template declaration of 'constexpr const T pi'
constexpr T pi = T(3.1415926535897932385);
^
How to enable C++14 features when using a qmake project in QtCreator?
I am using Qt 5.3.2, Qt Creator 3.2.1, and MinGW 4.8.2 32 bit.
This is now supported properly from Qt 5.4. You just type this into your qmake project file:
CONFIG += c++14
The necessary code change went in the middle of 2014 by Thiago:
Add support for CONFIG += c++14
I have just created the necessary documentation change:
Mention the c++14 CONFIG option in the qmake variable reference
Please note that variable templates are only supported from gcc 5.0, but then your code works just fine. This can be used for testing C++14 with older gcc:
main.cpp
#include <iostream>
int main()
{
// Binary literals: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
// Single-quotation-mark as a digit separator: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf
std::cout << 0b0001'0000'0001;
return 0;
}
main.pro
TEMPLATE = app
TARGET = main
CONFIG -= qt
CONFIG += c++14
SOURCES += main.cpp
Build and Run
qmake && make && ./main
Output
257
Qt Creator is just an IDE.
You can think of IDEs as "smarter text editors" that aid the developer with debugging, building, code completion, file management and so on.
IDEs are irrelevant during compilation.
What matters is your compiler. And it is independent from your IDE.
g++ 4.8.x does not support many C++14 features: check out this page to learn what C++14 features are supported.
For some weird reason this is what Qt does:
If the compiler is gcc or mingw, CONFIG+=C++14 is transformed to a compiler flag -std=c++14 (that what you expect)
If it's another compiler (like clang), CONFIG=C++14 is stupidly transformed to -std=c++11 (sic!), so you will get errors about unsupported features, even if your clang version correctly supports C++14.
To fix it, specify the flag explicitly:
QMAKE_CXXFLAGS += -std=c++14
This way, you're sure that your compiler (g++, mingw or clang) will receive the correct flags.
To use C++14 with qmake with versions before Qt 5.4 (it doesn't make any difference wether you use it with Qt Creator or with some other IDE or from command line) and gcc, add this to your .pro file:
QMAKE_CXXFLAGS += -std=c++1y
qmake got support for CONFIG += c++14 with Qt 5.4, so you can use that for projects where you are comfortable with requiring at least that version of Qt. Be sure to either use the explicit compiler flags, or use the CONFIG option, but not both at the same time, to avoid conflicting switches.
Unfortunately gcc 4.8.2 supports very few C++14 features (see here), but you can test that with this code snippet:
#include <iostream>
auto f() { return 42; }
int main()
{
std::cout << f() << std::endl;
}
That will compile fine with QMAKE_CXXFLAGS += -std=c++1y, but give warning with CONFIG += c++11 or QMAKE_CXXFLAGS += -std=c++1x.
--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.
I have a project that correctly compiles and runs under g++ 4.8.1 and clang >= 3.3 in c++11 mode. However, when I switch to the experimental -std=c++1y mode, clang 3.3 (but not g++) chokes on the <cstdio> header that is indirectly included by way of Boost.Test (so I cannot easily change it myself)
// /usr/include/c++/4.8/cstdio
#include <stdio.h>
// Get rid of those macros defined in <stdio.h> in lieu of real functions.
// ...
#undef gets
// ...
namespace std
{
// ...
using ::gets; // <-- error with clang++ -std=c++1y
// ...
}
with the following error message:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:119:11:
error: no member named 'gets' in the global namespace
On this tutorial on how to set up a modern C++ environment, a similar lookup problem with max_align_t is encountered. The recommendation there is to use a sed script to surround the unknown symbols with #ifdef __clang__ macros, but that seems a fragile approach.
Setup: plain 64-bit Linux Mint 15 with
g++ (Ubuntu 4.8.1-2ubuntu1~13.04) 4.8.1
Ubuntu clang version 3.3-3~raring1 (branches/release_33) (based on
LLVM 3.3)
Questions:
what is causing this erorr? There is no __clang__ macro anywhere near the code in question, and clang in c++11 mode has no trouble at all.
Is it a language problem (does C++14 say something else than C++11 about importing C compatible symbols from the global into the std namespace)?
Do I need to change something with my include paths? (I use CMake to automatically select the header paths, and switch modes inside CMakeLists.txt)
Does clang have a switch to resolve this?
This note in the gets manpage looks relevant:
ISO C11 removes the specification of gets() from the C language, and since version 2.16, glibc header files don't expose the function declaration if the _ISOC11_SOURCE feature test macro is defined.
Probably should be
#if !_ISOC11_SOURCE
using ::gets;
#endif
I'm having the same problem described in this post except I'm using Intel version 12.1.3. (g++'s header <functional> is protected with #ifdef __GXX_EXPERIMENTAL_CXX0X__ which is not defined when icpc is used.)
Instead of using boost::functional, I wanted to install gcc4.7 and use it's std libraries.
In Ubuntu 11.10 I have gcc4.6.1 but I also installed gcc4.7 from the gcc-snapshot package.
Intel has the options -gcc-name, -gxx-name, and -cxxlib.
So originally I compiled with:
-std=c++0x -gcc-name=/usr/lib/gcc-snapshot/bin/gcc -gxx-name=/usr/lib/gcc-snapshot/bin/g++ -cxxlib=/usr/lib/gcc-snapshot/
but I get the error:
icpc: error #10282: file
'/usr/lib/gcc-snapshot/bin/usr/lib/gcc-snapshot/bin/g++' not found,
generated based on '-cxxlib=/usr/lib/gcc-snapshot/'
So then I compiled with:
-std=c++0x -gcc-name=./gcc -gxx-name=./g++ -cxxlib=/usr/lib/gcc-snapshot/.
But I still get the warnings and errors:
Warning #2928: the __GXX_EXPERIMENTAL_CXX0X__ macro is disabled when using GNU version 4.6 with the c++0x option
error: namespace "std" has no member "function"
The warning clearly says it's still using version 4.6. Does anybody know how to get Intel to use the correct libraries?
I've found that if you compile with gcc (or g++) with flags -v -Q you get a list of flags and defines. It might help you see what gcc does so maybe you can use the same -D/-U in icpc. also g++ -E will preprocess without compiling: you can get useful path information from that.