I got some quite strange errors compiling code under gcc. It tells me that std::function does not exist.
I can recreate the error with the following code:
#include <functional>
#include <stdio.h>
void test(){ printf ("test"); }
int main() {
std::function<void()> f;
f = test;
f();
}
If I run gcc (from cygwin): (my error message was German, so i translated it. It may be sound different on a English gcc)
$ gcc test.cpp
test.cpp: in function "int main():
test.cpp:7:3: Error: "function" is not an element of "std"«
test.cpp:7:25: Error: "f" was not defined in this scope
With MSVC it compiled successfully.
Please tell me what I am doing wrong in my code.
Johannes
Compile it as:
g++ test.cpp -std=c++0x
-std=c++0x is needed because you're using C++11 features, otherwise g++ test.cpp is enough.
Make sure you've latest version of GCC. You can check the version as:
g++ --version
You need to compile in C++ mode, and in C++11 mode. So you need g++ and the -std flag set to c++0x.
g++ test.cpp -std=c++0x
You can also use -std=c++11 from gcc 4.7 onwards.
Related
I was attempting to compile and run the example on this page that explores function pointers as a function input. The example I was running was the 66 line one about halfway down the page.
https://www.learncpp.com/cpp-tutorial/function-pointers/
I am on Mac iOS 12.3.1. I tried to compile with
g++ sort.cc
and was getting errors that no semicolons were in my for loops, i believe due to the bracket initialization throughout the code. And when I run it with:
g++ -std=c++11 sort.cc
It works fine.
BUT
Shouldn't my clang be compiling at at least C++11? running
clang -v
I get
Apple clang version 13.1.6 (clang-1316.0.21.2)
Target: x86_64-apple-darwin21.4.0
And from what I can tell clang versions past 4 default to c++14.
Also, when I run using clang or gcc I get errors setting -std=c++xx, but it works fine with g++. But as far as I can tell, g++ and gcc are aliases to clang, and running gcc -v or g++ -v gives me clang version 13.1.6.
So whats going on?
Xcode clang defaults to C++98. Compiling a simple program which has C++11 or later features will tell you that C++11 or later isn't the default. e.g.,
// a.cpp
constexpr int i = 10;
clang a.cpp -c
a.cpp:1:1: error: unknown type name 'constexpr'
constexpr int i = 10;
^
1 error generated.
while clang a.cpp -c -std=c++11 works fine.
Also see: https://trac.macports.org/wiki/CompilerSelection
I'm experimenting with Clang "modules" feature, and I'm trying to compile following piece of code:
export module a;
#include <new>
export void *foo()
{
return ::operator new(1, std::align_val_t(1));
}
export int main() {}
Try it live
When I tried clang++ -std=c++2a -pedantic-errors -fmodules-ts --precompile -x c++-module a.cpp -o a.pcm, I got
error: ISO C++ requires a definition in this translation unit for function 'operator new'
because its type does not have linkage [-Werror,-Wundefined-internal-type]
a.cpp:7:14: note: used here
return ::operator new(1, std::align_val_t(1));
^
1 error generated.
Removing -pedantic-errors fixes the error, but when I try to link the resulting module using clang++ -std=c++2a -fmodules-ts a.pcm -o a.exe, I get
Z:\Lander\msys2\tmp\a-cfaf65.o:a.pcm:(.text+0x10): undefined reference to
`_ZnwyW1aESt11align_val_t'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
It's especially annoying since <iostream> (indirectly) seems to rely on the aligned operator new, so I can't use it in modules too. As well as some other standard headers.
What's going on here?
It it's a Clang bug, how can I work around it?
My Clang is the latest version provided by MSYS2:
# clang++ --version
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-w64-windows-gnu
Thread model: posix
EDIT:
Filed a bug report, let's see what happens...
The standard library isn't part of your module a. So don't include the header after the export module a;. Include the header before that.
We are catching compiler errors when using sigemptyset on Cygwin under Newlib. The error occurs with a C++ compiler, but only when -std=XXX is used. Without a standard option, the test program compiles and executes as expected.
The test program is below, and the Cygwin header of interest follows. I don't see anything suspicious in the Cygwin header.
I've tried tricks like #define _GNU_SOURCE and #define _XOPEN_SOURCE 700. I've also tried tricks like using the global and std namespaces. Related, see What does -D_XOPEN_SOURCE do/mean? and Namespace issues in c++11?.
What is causing the compile failure and how do I fix it?
$ cat ~/test.cxx
#include <signal.h>
int main(int argc, char* argv[])
{
struct sigaction new_handler;
return sigemptyset(&new_handler.sa_mask);
}
Without a -std=XXX, it results in:
$ g++ -c test.cxx
$
With a -std=XXX, it results in:
$ g++ -std=c++03 -c test.cxx
test.cxx: In function int main(int, char**):
test.cxx:6:44: error: sigemptyset was not declared in this scope
return sigemptyset(&new_handler.sa_mask);
And when trying to use sigemptyset in the global namespace:
$ g++ -std=c++03 -c test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:6:12: error: ‘::sigemptyset’ has not been declared
return ::sigemptyset(&new_handler.sa_mask);
^
Things get worse when using -std=gnu++03 and friends.
The function is an extension over the ISO C standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigemptyset.html
as such is protected on /usr/include/sys/signal.h by
__XSI_VISIBLE >= 4
see /usr/include/sys/features.h for details.
As defaults the largest definition set is used, but -std=XXX reduces the definition scope
The issue was worked through at Botan 2.1.0 does not compile under Cygwin 2.8.0 with g++ 5.4.0. Here are the two comments of interest.
First, from noloader:
Cygwin uses Newlib, not GNU's libstdc++. When there's no
-std=c++XX, current GCC defaults to -std=gnu++11 (GCC 6 changes
to gnu++14 by default). I
believe GNU sources ensures expected functions, like sigaction, are
available.
You might consider trying -D_XOPEN_SOURCE=600 or
-D_XOPEN_SOURCE=700.
Also see C++ and feature guards Warning
Question on the
Newlib mailing list.
Second, from SideChannel:
Thanks to #noloader. Until now -std=c++11 was set in Makefile. The
important info is in above mentioned thread on the Newlib mailing
list. Yaakov Selkowitz wrote:
G++ defines _GNU_SOURCE on glibc targets, meaning that -std=c++NN is, contrary to the documentation, not strict ISO C++:
So, applying the patch #987
AND setting -std=gnu++11 works for me. I
did not try the other -D options (I think the other fact is more
fundamental). Summarizing, #randombit please apply the PR #987 and set
-std=gnu++11 for gcc under Cygwin.
My code:
#include <iostream>
#include <string>
int main()
{
std::string test = "45";
int myint = std::stoi(test);
std::cout << myint << '\n';
}
Gives me the compile error:
error: 'stoi' is not a member of 'std'
int myint = std::stoi(test);
^
However, according to here, this code should compile fine. I am using the line set(CMAKE_CXX_FLAGS "-std=c++11 -O3") in my CMakeLists.txt file.
Why is it not compiling?
Update: I am using gcc, and running gcc --version prints out:
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
In libstdc++, the definitions of stoi, stol, etc., as well as the to_string functions, are guarded by the condition
#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
&& !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))
I have had this fail on one platform before (namely Termux on Android), resulting in to_string not being available even with g++ 6.1 and the C++14 standard. In that case, I just did
#define _GLIBCXX_USE_C99 1
before including anything, and voilà, suddenly the functions existed. (You should put this first, or even on the command line, rather than just before including <string>, because another header may include <string> first, and then its include guards will keep it from ever seeing your macro.)
I did not investigate why this macro wasn't set in the first place. Obviously this is a cause for concern if you want your code to actually work (in my case I didn't particularly, but FWIW there were no problems.)
You should check if _GLIBCXX_USE_C99 is not defined, or if _GLIBCXX_HAVE_BROKEN_VSWPRINTF is defined (which may be the case on MinGW?)
std::stoi is a C++11 function. You have to use the -std=c++11 to enable it in both g++ and clang++. This is the actual issue, not a linking error or a specific preprocessor define.
$ cat test.cxx
#include <iostream>
#include <string>
int main()
{
std::string test = "45";
int myint = std::stoi(test);
std::cout << myint << '\n';
}
$ g++ -otest test.cxx
test.cxx: In Funktion »int main()«:
test.cxx:7:17: Fehler: »stoi« ist kein Element von »std«
int myint = std::stoi(test);
^
$ g++ -otest test.cxx -std=c++11
$ ./test
45
$
edit: I just saw that you used c++11. Are you sure that's making it into your compile options? Check the generated makefile and watch the executed commands to be certain.
Your version seems up to date, so there shouldn't be an issue. I think it may be related to gcc. Try g++ instead.(Most likely automatically linking issue. If you just run gcc on a C++ file, it will not 'just work' like g++ does. That's because it won't automatically link to the C++ std library, etc.). My second advise is try std::atoi.
# I have fixed the issue. std::stoi uses libstdc++. It is about The GNU Standard C++ Library. In gcc you have to link adding -lstdc++. However, in g++, libstdc++ is linked automatically.
using gcc and using g++
Pay attention how it is compiled
using g++: g++ -std=c++11 -O3 -Wall -pedantic main.cpp && ./a.out
using gcc: gcc -std=c++11 -O3 -Wall -pedantic -lstdc++ main.cpp && ./a.out
I think you should set flag like set(CMAKE_EXE_LINKER_FLAGS "-libgcc -lstdc++") (Not tested)
#include <cstdlib>
int myInt = std::atoi(test.c_str());
If you are using Cmake to compile, add line:
"add_definitions(-std=c++11)"
after find_package command.
Use 'set(CMAKE_CXX_STANDARD 11)' for Cmake
I just (re)installed MinGW from scratch, with gcc 4.8.1 (the latest available), and the following program won't compile:
#include <iostream>
#include <string>
int main()
{
float f;
std::string s = "5.235";
f = std::stof(s);
std::cout << f << '\n';
}
Here's the command I use:
g++ -std=c++11 -o test test.cpp
I get this error:
test.cpp:8:9: error: 'stof' is not a member of 'std'
f = std::stof(s);
^
The file bits\basic_string.h which declares std::stof is included properly in the string header, and I checked bits\basic_string.h for std::stof's declaration, and it's there.
After a bit of Googling I did find some old patches for MinGW (4.6 - 4.7) but they seem irrelevant since I'm on gcc 4.8.
Any ideas? Thanks in advance.
Not sure about exact problem, but check mingw-w64 they have gcc 4.9.2 for now. It compiles your code just well. (But since the mingw-w64 project on sourceforge.net is moving to mingw-w64.org it's better to use mingw-w64.org)
Despite of it's name it provides compilers for both x86 and x64 targets.
Probably this should be a comment, not an answer.