The std::to_string functions are guarded by !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF). MinGW defines this symbol as 1 in its os_defines.h, with a comment pointing to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 That bug was marked as "resolved" over three years ago, but the fix was just to add this guard, not to actually get the functions to work. Can this be fixed so that the to_string functions work on MinGW?
Kai, is this fixed for 4.7.0?
*Ping* Could this please be fixed for 4.7?
Probably not since the trunk is in stage4. This isn't a regression and mingw isn't a primary target. Someone with access to a mingw system would have to do it anyway, which as far as I know rules out all the libstdc++ maintainers.
I'm pretty sure that Kai / the target maintainers did some work to actually make available the underlying libc function on those systems, thus I can imagine that just tweaking a bit the configury could do the trick, and in that case a fix could go in for 4.7.1. Well, if Kai can tell us that the tweak is *really* trivial and totally restricted to MinGW, maybe even 4.7.0, conditional to release managers approval, of course.
PS (note to the library maintainers): if I remember correctly the resolution of some relatively recent DRs, these conversion functions have to do the work in any case in the C locale, thus we'll have to adopt here too the dance used in c_locale.cc / c_locale.h.
(In reply to comment #4) > I'm pretty sure that Kai / the target maintainers did some work to actually > make available the underlying libc function on those systems, thus I can > imagine that just tweaking a bit the configury could do the trick, and in that > case a fix could go in for 4.7.1. Well, if Kai can tell us that the tweak is > *really* trivial and totally restricted to MinGW, maybe even 4.7.0, conditional > to release managers approval, of course. Well, I thought about fixing this issue for 4.7 using mingw-w64's runtime. It should be doable, as mingw-w64 provides also wide printf/scanf (and ansi scanf) functions with glibc behavior. The dfp aren't supported there right now, but this is something we will come up in future. Also for 4.7 libstdc++ uses for mingw-w64 configure variant by default posix-compatible printf/scanf API. I didn't found time to dive in more detail into this issue.
I see. Definitely post 4.7.0 then.
As mentioned before this bug is still active in GCC 4.7.0. The issue got additionally mentioned in the MinGW bug tracker: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3413241&group_id=2435 There's a possible patch for it at: http://tehsausage.com/mingw-to-string Since it's not clear how long that website will be up, I'll post it here again: ______________________________________ 24 August 2012, 11:16 UTC This patch enables the following list of C++11 functions and templates in the std namespace: stoi, stol, stoul, stoll, stof, stod, stold, to_string, to_wstring This assumes you are using the official MinGW distribution. If you are applying this patch to a version of MinGW GCC later than 4.7, you should examine and apply the patches rather than using the zip file. * Download mingw-to-string-gcc47.zip which contains three patched header files. (Original patches: wchar.h, stdio.h, os_defines.h) * Copy wchar.h and stdio.h from the include directory in the zip file to the following directory (overwrite): C:\mingw\include (replace C:\mingw\ with the appropriate directory) * Copy os_defines.h to the following directory (overwrite): C:\mingw\lib\gcc\mingw32\4.7.0\include\c++\mingw32\bits (replace C:\mingw\ with the appropriate directory) (replace 4.7.0 with the correct version number) Author: Julian Smythe
Created attachment 28191 [details] Enabling string conversion functions in MinGW Patch from: http://tehsausage.com/mingw-to-string
Patch should be sent to the gcc-patches (and libstdc++) mailing list (any contributor must have a Copyright assignment on file, of course)
Ping. What is the status of this issue? Will it ever get any resolution?
(In reply to comment #11) > Ping. What is the status of this issue? Will it ever get any resolution? Only if someone who cares enough about this issue steps up and does the work. That could be you: http://gcc.gnu.org/contribute.html The patch attached here is not a proper fix, as stated by its author: "Also as stated in an email reply sent to someone regarding gcc bug #52015, this is not a proper MinGW patch. It can break existing programs using the Windows versions of [v]swprintf (as it replaces them with the standard signatures), might(?) cause problems if the functions aren't inlined, and it is applied to post-build MinGW so it cannot be guaranteed that future libstdc++ changes won't make enabling this impossible. The patch is also missing a call to __builtin_va_end." http://tehsausage.com/mingw-to-string
(In reply to comment #9) > Created attachment 28191 [details] > Enabling string conversion functions in MinGW > > Patch from: http://tehsausage.com/mingw-to-string That's a zip file, not a patch. I've fixed the attachment details. Maybe tehsausage's alternative implementations could be used under different names so they don't replace the system functions, and have mingw use those alternative names. The changes don't look significant enough to need a copyright assignment/disclaimer anyway, they just forward from one function to another. The configure check that sets _GLIBCXX_HAVE_BROKEN_VSWPRINTF could check for working _vsnwprintf and make that usable instead.
patch posted to http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02544.html stay tuned
My ok JonY has for the patch of 4.8. It is related to a fix present upstream in mingw-w64 about snprintf-arguments for POSIX-mode. So I don't intend to have this patch backported to 4.7, nor I think we can enable feature for none mingw-w64 targets due differences in venture's implementations. It would be good if a c++-maintainer could comment on http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02711.html Kai
Already in mainline: 2012-10-31 Jonathan Yong <jon_y@users.sourceforge.net> * config/os/mingw32-w64/os_defines.h: Do not define anymore _GLIBCXX_HAVE_BROKEN_VSWPRINTF. If a backport isn't expected, please just close as fixed for 4.8.0.
(In reply to comment #16) > Already in mainline: > > 2012-10-31 Jonathan Yong <jon_y@users.sourceforge.net> > > * config/os/mingw32-w64/os_defines.h: Do not define anymore > _GLIBCXX_HAVE_BROKEN_VSWPRINTF. Thanks for the head's up. I was just looking at ML's thread and thought it would be still pending. > If a backport isn't expected, please just close as fixed for 4.8.0. Yes, there won't be a backport from my side, so closing report.
(In reply to comment #17) > Thanks for the head's up. I was just looking at ML's thread and thought it > would be still pending. Sorry, I broke the thread by replying to a different post, because the patch wasn't originally posted to the libstdc++ list. It continued at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02886.html
Why not apply to gcc-4_7-branch?
(In reply to comment #19) > Why not apply to gcc-4_7-branch? A user who can build 4.7.2 successfully should not have to update their OS to build 4.7.3
(In reply to comment #20) > (In reply to comment #19) > > Why not apply to gcc-4_7-branch? > > A user who can build 4.7.2 successfully should not have to update their OS to > build 4.7.3 Huh? What requires updating your OS?
OS wasn't the right term, but you need to update mingw32-w64 to a recent version from trunk. That requirement is not suitable for a release branch.
Nathan, read comment 15. :)
just downloaded mingw32 version 4.8.1, and it still doesn't seem to be fixed. Still getting error: 'to_string' is not a member of 'std'. Status should be changed? ..
See comment 15 - it's only fixed if you use mingw-w64, and is not possible to fix for mingw
(In reply to Jonathan Wakely from comment #25) > See comment 15 - it's only fixed if you use mingw-w64, and is not possible > to fix for mingw Not possible? I doubt that. If you need the participation of (one of) the developers at MinGW.org -- to implement support in our runtime library, for example -- you have only to ask. Of course, if you restrict your communications to within your own little clique, a solution is less likely to be forthcoming.
I'm pretty sure that nobody here is artificially restricting communications. Most of us simply don't know enough about mingw and trust our target maintainers (Kai, Christopher, and Dave). I think that in general this is a sensible way to manage a large project like GCC. I'm adding Christopher and Dave too in CC, anyway.
Nobody restricts here any communications. The description in comment #15 is right now describing just the facts. That nobody of the mingw.org team is active on gcc-upstream, is for sure not gcc's community problem. You misjudge your importance pretty much. It is not up to gcc-community to involve you. Nobody waits for you, nor miss you ... Actual your clique might want to be more active on suggestions, providing improvements, patches, new features, etc for mingw 32-bit target ... but this we hadn't seen for long time now. So the conclusion of all here is my advice for you: "si tacuisses philosophus mansisses". Try to bring things forward, not blaming others for your ignorance.
(In reply to Kai Tietz from comment #28) > Nobody restricts here any communications. The description in comment #15 is > right now describing just the facts. That nobody of the mingw.org team is > active on gcc-upstream, is for sure not gcc's community problem. > You misjudge your importance pretty much. It is not up to gcc-community to > involve you. Nobody waits for you, nor miss you ... > Actual your clique might want to be more active on suggestions, providing > improvements, patches, new features, etc for mingw 32-bit target ... but > this we hadn't seen for long time now. > > So the conclusion of all here is my advice for you: "si tacuisses > philosophus mansisses". Try to bring things forward, not blaming others for > your ignorance. Precisely the sort of cliquey arrogance which I find so offensive, in GCC. Not one of the three, named by Paolo, is in any way associated with MinGW.org, (the originator of the name MinGW, which you so gratuitously abuse). Granted, MinGW.org could be more forthcoming in appointing a project liaison, but given this level of arrogant abuse, is it any wonder that none is stepping up to the plate?
(In reply to Keith Marshall from comment #29) > Granted, MinGW.org could be more forthcoming in appointing a > project liaison, but given this level of arrogant abuse, is it any wonder > that none is stepping up to the plate? So do you expect GCC devs who don't even own a Windows machine to liase instead? Not gonna happen, sorry.
Or to put it another way, this bug only affects MinGW users, is blocked by a limitation in MinGW, and noone from MinGW has offered to do anything about it, but you're pointing fingers at GCC devs and saying there's a GCC clique? Who is preventing MinGW devs joining this clique? If you want to improve the situation I suggest not throwing around words like abuse, and instead gently correcting misunderstandings by demonstrating that this can indeed be fixed in MinGW. But that fix probably has to come from MinGW.
(In reply to Jonathan Wakely from comment #31) > Or to put it another way, this bug only affects MinGW users, is blocked by a > limitation in MinGW, and noone from MinGW has offered to do anything about > it, but you're pointing fingers at GCC devs and saying there's a GCC clique? > Who is preventing MinGW devs joining this clique? No one, but they need to know about issues like this in order to do something about them. Above you said that this was "not possible" to fix for mingw. If you really meant "this would require changes in the mingw runtime", perhaps you should have said that. Then, even if you are not motivated to approach the MinGW developers to effect such changes, someone else (e.g. me) could have.
(In reply to Nathan Ridge from comment #32) > No one, but they need to know about issues like this in order to do > something about them. It's been in the MinGW bug tracker for years, although now closed as "out of date" > Above you said that this was "not possible" to fix for > mingw. It's not possible to fix in GCC without extraordinary effort for a single target, which is not going to happen. If a given target wants to support C++11 features then it needs to provide the necessary C99 features. This is not a GCC issue. > If you really meant "this would require changes in the mingw > runtime", perhaps you should have said that. Then, even if you are not > motivated to approach the MinGW developers to effect such changes, someone > else (e.g. me) could have. Fine. How about some ACTUALLY DOES SOMETHING USEFUL instead of quibbling over the particular wording I used in a bugzilla comment?
*** Bug 59076 has been marked as a duplicate of this bug. ***
Tried to apply proposed patch for MinGW 4.8.1 and received no positive effect. Compiler tells about error : 'stoi' was not declared in this scope. Have any Idea how to fix it?
(In reply to Roman from comment #35) > Tried to apply proposed patch for MinGW 4.8.1 and received no positive > effect. Compiler tells about error : 'stoi' was not declared in this scope. > Have any Idea how to fix it? Not enough information to be useful. Did you even use -std=c++11 ? Noone here can debug your modified sources, you'll have to look into what is or isn't defined on your system after the patch. Try looking at the preprocessed source, for example.
Created attachment 32220 [details] initilal file
Created attachment 32221 [details] yeld without -std=c++11
Created attachment 32222 [details] yeld with -std=c++11
(In reply to Jonathan Wakely from comment #36) > (In reply to Roman from comment #35) > > Tried to apply proposed patch for MinGW 4.8.1 and received no positive > > effect. Compiler tells about error : 'stoi' was not declared in this scope. > > Have any Idea how to fix it? > > Not enough information to be useful. > > Did you even use -std=c++11 ? Yes, shure. > > Noone here can debug your modified sources, you'll have to look into what is > or isn't defined on your system after the patch. Try looking at the > preprocessed source, for example. I'm not familiar with such a matter. Attached files are: stoi.cpp is initial code stoi_prep.cpp is result of g++ stoi.cpp -E > stoi_prep.cpp stoi_prep11.cpp is result of g++ stoi.cpp -E -std=c++11 > stoi_prep11.cpp