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
Related
The date library is very useful but you can see a lot of warnings after compiling a simple example that uses date library.
for example:
#include "date.h"
int main() {
using namespace date;
std::cout << weekday{July/4/2001} << '\n';
}
compiled with:
g++ -c -Waggregate-return main.cpp
warning: function call has aggregate value [-Waggregate-return]...
Depending on the version of your compiler, C++11 (or later) mode might not be active, so try adding -std=gnu++0x at least. Also you code needs #include <iostream> added.
To fix these warnings you should remove the flag -Waggregate-return from your compile string. This flag causes warnings for valid code.
Note that you also need #include <iostream>, and for older versions of g++ , -std=c++14 or a similar flag.
#include <iostream>
using namespace std;
int main(){
std::cout << "Hello World\n";
return 0;
}
command 1 (works)
clang hello.cc -o hello -lc++
command 2 (don't works)
/path/to/custom/clang hello.cc -o hello -lc++
main.cc:2:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Why I can't compile with command 2 ?
It looks like you're trying to compile C++ with a C compiler. Try running clang++ instead.
clang++ hello.cc -o hello
Without running clang as a C++ compiler it won't have the C++ standard library headers available for you to include. Using clang++ the C++ standard library headers are available and the C++ standard library is linked for you automatically.
That is a known Ubuntu issue. Their clang just isn't set up right. I complained about it here -- and this remained unfixed for years.
But the good news is that it now works with the most recent 16.10 release.
Edit: Based on your updated question I would say that "custom clang" does not know about its include files.
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.
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.
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.