33

I tried compiling this simple program on IdeOne (which uses gcc 4.5.1) and on my Linux computer (which uses something like 4.6.4):

#include <string>
#include <iostream>

int main() {
     std::cout << std::stoi("32") << std::endl;
}

And it compiles perfectly and outputs 32. However, when I try to compile it on my windows computer with MinGW and gcc 4.6.1, I get this error:

test.cpp: In function 'int main()':
test.cpp:5:19: error: 'stoi' is not a member of 'std'

The same happens with std::stoul, etc. Does std::stoi and family not exist in MinGW for some reason? I thought gcc on MinGW (sh|w)ould behave the same as on Linux.

Seth Carnegie
  • 73,875
  • 22
  • 181
  • 249
  • 1
    @KerrekSB yes: `g++ -std=c++0x test.cpp` – Seth Carnegie Dec 17 '11 at 02:51
  • MinGW isn't maintained by the same group as GCC itself, so it's not always up to date. – Benjamin Lindley Dec 17 '11 at 02:51
  • @BenjaminLindley does that mean that when you do `g++ -v` on MinGW and you get a certain version, it doesn't mean anything as to what features it implements? – Seth Carnegie Dec 17 '11 at 02:52
  • 1
    @Seth: Well, that tells you the version of the compiler. It doesn't tell you much about the standard library. – Benjamin Lindley Dec 17 '11 at 02:54
  • @BenjaminLindley is there any way I can tell that, or upgrade it somehow? – Seth Carnegie Dec 17 '11 at 02:56
  • @Seth: Surely, but I don't know the ins and outs of that. I believe I have the same version a you. Where did you get yours btw? because I don't think MinGW uses 4.6 yet. I got mine from [here](http://nuwen.net/). And I think all Stephan did was update the compiler itself, not the libraries. – Benjamin Lindley Dec 17 '11 at 03:00
  • @BenjaminLindley I downloaded MinGW from [here](http://www.mingw.org/). That sucks, now I can't compile my project on Windows :( – Seth Carnegie Dec 17 '11 at 03:53
  • 4
    I have contacted the MinGW-w64 developers about this. To me, this is just libstdc++ devs being lazy. – rubenvb Dec 17 '11 at 10:08

4 Answers4

46

This is a result of a non-standard declaration of vswprintf on Windows. The GNU Standard Library defines _GLIBCXX_HAVE_BROKEN_VSWPRINTF on this platform, which in turn disables the conversion functions you're attempting to use. You can read more about this issue and macro here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522.

If you're willing to modify the header files distributed with MinGW, you may be able to work around this by removing the !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) macro on line 2754 of .../lib/gcc/mingw32/4.6.1/include/c++/bits/basic_string.h, and adding it back around lines 2905 to 2965 (the lines that reference std::vswprintf). You won't be able to use the std::to_wstring functions, but many of the other conversion functions should be available.

DRH
  • 7,868
  • 35
  • 42
  • 4
    Brilliant, worked perfectly. This hack will have to do until they properly fix it. It seems stupid to me that they would actually _disable some functions in the standard library_ rather than actually fix something, but I guess they had their reasons. – Seth Carnegie Dec 17 '11 at 18:47
  • 3
    If I can do this and things working, why didn't they just move the `#if` down a few lines? – Seth Carnegie Dec 17 '11 at 18:51
  • 6
    This issue also affected std::to_string, and moving the macro below those lines allowed me to use that function. – GravityWell Oct 27 '12 at 02:42
  • 1
    Just had to do this to MinGW 10.2 which reports gcc version 4.8.1. – Kate Gregory Jun 16 '13 at 17:26
  • It is the cure even in MinGW 64 4.8.1 – Amos Apr 17 '14 at 14:24
  • Same for MinGw with gcc-g++ version 4.8.1-4 – toussa Sep 25 '14 at 14:24
  • gcc --version tdm-2 4.8.1 has this problem as of 2014-DEC-01 thus it rears its ugly head in Code::Blocks as well – Brian Jack Dec 01 '14 at 15:49
  • Why won't the MinGW people fix this even after a YEAR (or more!!!) of the problem??? It's been there since 4.6.x – Brian Jack Dec 01 '14 at 15:51
  • 1
    @SethCarnegie The issue is there are two projects: g++ and mingw - the g++ devs added the guard as a warning to the mingw devs that something in their end is needed fix the issue. There seem to be some political issues going on that stifle communication between the mingw devs and the g++ devs. As a result of this mess there still fails to be an 'official' fix as of 2014-DEC-01 – Brian Jack Dec 01 '14 at 16:00
6

This is fixed in MinGW-w64, a fork of the original MinGW project that actually is interested in fixing bugs like this. It was fixed as of g++ 4.9.2, and maybe earlier.

Note: for people coming here who have done a default install of CodeBlocks (which comes with the old, broken MinGW), and want to upgrade the compiler, see this answer.

You can use any build of MinGW-w64: I use the self-installer from mingw-builds.org, whereas that answer uses TDM-GCC-64. If you want both 64bit and 32bit compilation you need to install and add 2 new compilers: mingw-w64 64-bit, and mingw-w64 32-bit. It does NOT support using one installation of g++ with the -m32 or -m64 switch to toggle.

Community
  • 1
  • 1
M.M
  • 138,810
  • 21
  • 208
  • 365
  • Note: for people coming here who have done a default install of CodeBlocks (which comes with the old, broken MinGW), and want to upgrade the compiler, [see this answer](http://stackoverflow.com/a/27688821/1505939). You can use any build of MinGW-w64: I use the self-installer from mingw-builds.org, whereas that answer uses TDM-GCC-64. – M.M Oct 26 '16 at 21:55
0

I am using MinGW 4.9.3-1. This problem seems to be still there. As a workaround, I used the another way of getting integers from strings. 

int rows, columns;
sscanf(argv[1], "%d", &rows);
sscanf(argv[2], "%d", &columns);
ashish
  • 425
  • 4
  • 11
0

Use Mingw-w64. I had this same issue and using Mingw-w64 worked for me.

Sean Nolan
  • 25
  • 3