I have found many questions to this topic but all problems seem to be related to not compiling with C++ 11. My code is
#include <random>
int main(int argc, char *argv[]){
std::default_random_engine generator;
return 0;
}
even though I compile with
gcc -std=c++0x testmain.cpp
Giving the error that default_random_engine is not a member of std. The program is compiled on a remote machine, which I do not maintain myself but
gcc -v
yields a version of 4.4.7.
Any ideas?
For others:
Check if you actually include random with #include <random>. I didn't have it and some other header included it previously. Now that header got updated and I got this error and didn't find it for a while because I was checking compiler settings.
As DevSolar already stated, your gcc version is too old, to support this C++11 feature.
It was added in gcc-4.5:
Improved experimental support for the upcoming ISO C++ standard,
C++0x, including:
Support for <future>, <functional>, and <random>.
Reference: https://gcc.gnu.org/gcc-4.5/changes.html
This is also reflected by the libstdc++ API Reference: https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api-4.5/a01118.html
where you can find the following:
typedef minstd_rand0 default_random_engine
Your code works fine for me in: gcc-5.1.0, gcc-4.9.2 and clang-3.7.0,
Also you should use the command: g++ instead of gcc so gcc links against proper c++ libraies by default.
Your problem is you're not compiling with C++11. ;-) (Sorry, could not resist.)
GCC 4.4.7 is dated March 2012. C++11 support was not yet complete in that version.
As of the time of this writing, the current version of GCC is 5.2.0... which is C++14 compliant. Time to update your compiler. ;-)
I hate to recommend this but in your case (old untouchable machine) I can offer a suggestion. The tr1 version of the random library should be available for g++-4.4:
#include <tr1/random>
int main(int argc, char *argv[]){
std::tr1::default_random_engine generator;
return 0;
}
There have been improvements in the std version relative to tr1 version but you should be able to use most <random> features.
You don't even need C++0x.
Related
I can compile the following code (using std::transform_reduce) with gcc 9.2.1 on both Fedora and Ubuntu, but attempting to compile on clang see godbolt fails, and I've got a report that some FSF version of gcc 9.2.1 also refuses to compile the code, requiring a std::execution_policy as the first argument to the std::transform_reduce.
#include <vector>
#include <algorithm>
#include <numeric>
auto brokenvector(std::vector<int> const& a, std::vector<int> const& b)
{
return std::transform_reduce(cbegin(a), cend(a), cbegin(b), 0, std::plus<>{},std::multiplies<>{});
}
I specifically cannot use a std::execution_policy here, and both cppreference and the C++ draft standard document n4659 show overloads without an execution policy.
Have I stepped into some kind of political minefield where half of the available compilers refuse to implement the standard, or is the code incorrect?
This is a libstdc++ vs libc++ issue. libc++ implements the function and you can see it working with clang on godbolt using -stdlib=libc++ in this live example. gcc implements it now in trunk, but the currently released versions do not. The function was added in this commit.
I try to compile a simple c++ code in c++, but keep returning errors when I try to compile it with g++ in windows.
I use
g++ -std=c++0x -pthread main.cpp
The error messages are:
std::thread' is defined in header '<thread>'; did you forget to '#include <thread>'?
Which doesn't make sense because the code is just
#include<thread>
void f(int i) {}
int main() {
std::thread t(f, 1);
t.join();
return 0;
}
I believe this code works in linux, I wonder why it can't work under windows.
To use std::thread you must be compiling your code as C++11, C++14 or C++17.
You are passing -std=c++0x to gcc. c++0x was the name used for pre-release versions of the gcc C++11 impletation and, depending on your compiler version, may be incomplete.
Change your gcc command line to -std=c++11 and things most likely work better. If not, you may need to get a newer version of the compiler.
Windows has its own threading API that is not POSIX standard. What you need to find out is (how to acquire and) how to link the threading library for your compiler. It sounds like you're using MinGW? I use MSVC and it automatically links with the Windows threading libraries. Unfortunately I don't know how to do this for MinGW, so this isn't the best answer, but here is a link that might get you started:
Does MinGW-w64 support std::thread out of the box when using the Win32 threading model?
Here is my code:
#include <iostream>
#include <iomanip>
#include <complex>
#include <cmath>
int main()
{
using namespace std::complex_literals;
std::cout<< std::fixed<<std::setprecision(1);
std::complex<double> z1= 1i *1i; //imaginary unit squared
std::cout<<"i * i= " <<z1 <<'\n';
std::complex<double> z2=std::pow(1i, 2); //imaginary unit squared
std::cout <<"pow(i,2) =" <<z2 <<'\n';
}
I compile with gcc hello.cpp -lstdc++ -o hello.o
Basically it won't let me double the powers of a complex number when i do std::complex z2=std::pow(1i, 2);..
I get the following error
error: no matching function for call to 'pow(complex int, int)'
std::complex z2=std::pow(1i, 2);
However, if i remove the complex number and do std::complex z2=std::pow(2, 2);
it returns 4, the correct answer..
There are many more lines of compile errors, but i made it brief
This answer follows up the comments to the original question:
you have to force the compiler to use the c++14 standard with the -std=c++14 option because the literal operator""i is part of the C++14 spec.
GCC uses c++14 by default since version 6.1. Check your compiler version with gcc -v and refer to this link for GCC standard support.
EDIT:
I was able to reproduce the compiling issue with GCC 6.3 through the link provided by Mr Richard Critten in the comments to the original question, who was the first to point to the correct answer. My apology because I totally overlooked the reference to the C++14 standard.
Anyway, for the sake of clarity, I'm editing this answer, because I've found something that may be interesting to share.
The reason why compiling with GCC 6.3 fails is the fact that the reference standard has been changed in December 2016 from C++14 to GNU++14, see here.
GNU++14 is an extension to the C++ standard, that, among other things, provides additional functions overload for standard APIs.
I've found that with GNU++14 SFINAE fails in finding a proper overload for the std::pow() functions unless the type is explicitly set in the template call like in the snipped below:
std::complex<double> z2=std::pow<double>(1i, 2);
The GNU++14 includes changes to the cmath and complex header files, that I believe are the cause of the issue.
Turning on the C++14 flag, that is not the default anymore, fixes the problem.
I don't know why it is not compiling on your system, it runs fine on mine.
I think something is wrong with your compiler. And, not the version. yet you could try std::cout << __cplusplus. See what this prints.
C++11 doesn't recognize std::complex_literals, so doubt that is the case, but yet the compiler still couldn't find the function.
I honestly don't understand why it is searching for (complex int, int). The compiler is either corrupt or an old beta version.
You should either download a fresh version of the compiler or run it online somewhere. Try adding -std=c++14, but I doubt that would help.
Try your code here(it works):
https://www.jdoodle.com/online-compiler-c++14
So, I installed Microsoft Visual Studio.. I am using the clang compiler and my program ran smoothly with no errors!
Thanks for all the help guys, but i think clang is a better c++ compiler
I would like to write a "portable" C++ library in Clang. "Portable" means that I detect (in C preprocessor) what C++ features are available in the compilation environment and use these features or provide my workarounds. This is similar to what Boost libraries are doing.
However, the presence of some features depends not on the language, but on the Standard Library implementation. In particular I am interested in:
type traits (which of them are available and with what spelling)
if initializer_list being constexpr.
I find this problematic because Clang by default does not use its own Standard Library implementation: it uses libstdc++. While Clang has predefined preprocessor macros __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__, they are hardcoded to values 4, 2, 1 respectively, and they tell me little about the available libstdc++ features.
How can I check in Clang preprocessor what version of libstdc++ it is using?
Clang does come with its own standard library implementation, it's called libc++. You can use it by adding -stdlib=libc++ to your compile command.
That being said, there are various ways to check Clang/libstdc++ C++ support:
Clang has the __has_feature macro (and friends) that can be used to detect language features and language extenstions.
Libstdc++ has its own version macros, see the documentation. You'll need to include a libstdc++ header to get these defined though.
GCC has its version macros which you already discovered, but those would need to be manually compared to the documentation.
And also, this took me 2 minutes of googling.
This is what I think would help. It prints the value of the _LIBCPP_VERSION macro:
#include <iostream>
#include <string>
using namespace std;
int main(int argc, const char * argv[])
{
cout<<"Value = "<<_LIBCPP_VERSION<<endl;
return 0;
}
Compile it again the version of clang you want the info for.
The following simple code can't be compiled by g++ 4.3:
#include <array>
using namespace std;
int main()
{
std::array<int, 8> myarray;
return 0;
}
array: No such file or directory
Also, the compiler doesn't seen to understand option '-std=c++11' as is recommended to provide to the compiler. Is there another option?
Thanks.
GCC 4.3 and presumably also your C++ library are too old for the support you're looking for. You need a newer version. Here's a link to the GCC C++11 support page, and another link to the libstdc++ C++11 support page.
Alternatively, clang supports all of C++11 with libc++.
For me the problem was that it was a cross compiler that needed to be told where the sysroot was, and supplying --sysroot=<path to sysroot> allowed GCC to find the headers