[String Algo] error in ireplace_first or ireplace_all with std::wstring under gcc 3.4.2 (MingW)
I apologize in advance if this is an inappropriate place to post this question. I posted it to the boost-users list half a week ago and got no replies, so I am trying here instead. The following code compiles and runs without error under g++ in Windows, GCC 3.4.2 (MingW): <code> #include <cstdio> #include <string> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main( void ) { string test = "This is a test"; ireplace_first( test, "test", "success" ); printf( "%s\r\n", test.c_str() ); return 0; } </code> The output is correct: "This is a success". If I change the above code to use a std::wstring instead, it will compile, but it will crash on execution: <code> #include <cstdio> #include <string> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main( void ) { wstring test = L"This is a test"; ireplace_first( test, L"test", L"success" ); printf( "%ws\r\n", test.c_str() ); return 0; } </code> Setting a breakpoint on std::terminate() in gdb gives the following backtrace: Breakpoint 1, 0x00407ae6 in std::terminate() () (gdb) bt #0 0x00407ae6 in std::terminate() () #1 0x00404dc2 in __cxa_throw () #2 0x004021d2 in std::__throw_bad_cast() () #3 0x00434c69 in std::ctype<wchar_t> const& std::use_facet<std::ctype<wchar_t> >(std::locale const&) (__loc=@0x22fe8c) at C:/Applications/Dev-Cpp//bin//../lib/gcc/mingw32//3.4.2//..//..//../../include/c++/3.4.2/bits/locale_facets.tcc:112 #4 0x0043415c in wchar_t std::toupper<wchar_t>(wchar_t, std::locale const&) ( __c=84, __loc=@0x22fe8c) at C:/Applications/Dev-Cpp//bin//../lib/gcc/mingw32//3.4.2//..//..//../../include/c++/3.4.2/bits/locale_facets.h:4553 #5 0x0041648c in bool boost::algorithm::is_iequal::operator()<wchar_t, wchar_t> (wchar_t const&, wchar_t const&) const (this=0x22fe8c, Arg1=@0x3e3df4, Arg2=@0x43702e) at C:/Applications/Boost_new/boost/algorithm/string/compare.hpp:71 #6 0x004163fb in boost::iterator_range<__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>::operator()<__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >(__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, __gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >) const (this=0x22fe80, Begin={_M_current = 0x3e3df4}, End={_M_current = 0x3e3e10}) at C:/Applications/Boost_new/boost/algorithm/string/detail/finder.hpp:76 #7 0x00413fe8 in void boost::algorithm::find_format<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>, boost::algorithm::detail::const_formatF<boost::iterator_range<wchar_t const*> > >(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>, boost::algorithm::detail::const_formatF<boost::iterator_range<wchar_t const*> >) ( Input=@0x22ff50, Finder=@0x22fe80, Formatter={m_Format = {m_Begin = 0x43701e, m_End = 0x43702e, singular = false}}) at C:/Applications/Boost_new/boost/algorithm/string/find_format.hpp:146 #8 0x004141b5 in void boost::algorithm::ireplace_first<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, wchar_t[5], wchar_t[8]> (std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, wchar_t[5] const&, wchar_t[8] const&, std::locale const&) (Input=@0x22ff50, Search=@0x43702e, Format=@0x43701e, Loc=@0x22ff40) at C:/Applications/Boost_new/boost/algorithm/string/replace.hpp:259 #9 0x004014e8 in main () at test.cpp:11 I am not competent enough with Boost to understand what the call stack is telling me, except that __throw_bad_cast( ) is the source of the crash. ireplace_all gives the same behavior as ireplace_first above. Furthermore, the problem does not arise if I use replace_first or replace_all instead of ireplace_first or ireplace_all. It compiles and runs correctly. Finally, the problem does not arise if I compile using MSVC 2008. It compiles and runs correctly. Does this indicate a problem with gcc (MingW) unicode support? Is there an easy way to circumvent it? Thank you very much for any suggestions!
Hi, On Tue, Jan 19, 2010 at 06:34:48PM -0500, Doug Swanson wrote:
I apologize in advance if this is an inappropriate place to post this question. I posted it to the boost-users list half a week ago and got no replies, so I am trying here instead.
I'm sorry I missed that.
The following code compiles and runs without error under g++ in Windows, GCC 3.4.2 (MingW):
<snip>
Does this indicate a problem with gcc (MingW) unicode support? Is there an easy way to circumvent it?
Thank you very much for any suggestions!
As far as I know, that answer is quite simple. Unless something have changed recently, mingw does not support unicode strings. I would suggest to swith to non-mingw version of gcc. Best Regards. Pavol
Thank you so much for your reply! I really appreciate it. Although I remember reading about this issue at some point in the past, I have used std::wstring under MingW-gcc for quite some time now with no problems. If it were really 100% incompatible I would wish it would give a compilation error! I wonder why it crashes under the 'ireplace' algorithms but not the 'replace' ones -- especially since I remain strictly within Unicode Plane 0 (basic 2-byte characters in UTF-16/UCS-2 which fit in a single wchar_t on Windows). In any event, if you have any further insight here I would be interested to hear it, but I suppose I will just have to change compilers. Thanks again! Pavol Droba wrote:
Hi,
On Tue, Jan 19, 2010 at 06:34:48PM -0500, Doug Swanson wrote:
I apologize in advance if this is an inappropriate place to post this question. I posted it to the boost-users list half a week ago and got no replies, so I am trying here instead.
I'm sorry I missed that.
The following code compiles and runs without error under g++ in Windows, GCC 3.4.2 (MingW):
<snip>
Does this indicate a problem with gcc (MingW) unicode support? Is there an easy way to circumvent it?
Thank you very much for any suggestions!
As far as I know, that answer is quite simple. Unless something have changed recently, mingw does not support unicode strings. I would suggest to swith to non-mingw version of gcc.
Best Regards. Pavol
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 20-01-2010 18:41, Doug Swanson wrote:
Thank you so much for your reply! I really appreciate it.
Although I remember reading about this issue at some point in the past, I have used std::wstring under MingW-gcc for quite some time now with no problems. If it were really 100% incompatible I would wish it would give a compilation error! I wonder why it crashes under the 'ireplace' algorithms but not the 'replace' ones -- especially since I remain strictly within Unicode Plane 0 (basic 2-byte characters in UTF-16/UCS-2 which fit in a single wchar_t on Windows).
In any event, if you have any further insight here I would be interested to hear it, but I suppose I will just have to change compilers. Thanks again!
[snip]
As far as I know, that answer is quite simple. Unless something have changed recently, mingw does not support unicode strings. I would suggest to swith to non-mingw version of gcc.
How goes the difference between replace and ireplace? IIUC MinGW itself is as fully wide-aware as any other gcc, it's libstdc++ which is not under MinGW. Using MinGW with another standard library (STLPort for instance) should make your problems go away. However, since only one of the two algorithms fail, I wonder at their implementation. Does ireplace use some part of the standard library that replace does not? /Brian
On 20. 1. 2010 22:54, Brian Ravnsgaard Riis wrote:
On 20-01-2010 18:41, Doug Swanson wrote:
Thank you so much for your reply! I really appreciate it.
Although I remember reading about this issue at some point in the past, I have used std::wstring under MingW-gcc for quite some time now with no problems. If it were really 100% incompatible I would wish it would give a compilation error! I wonder why it crashes under the 'ireplace' algorithms but not the 'replace' ones -- especially since I remain strictly within Unicode Plane 0 (basic 2-byte characters in UTF-16/UCS-2 which fit in a single wchar_t on Windows).
In any event, if you have any further insight here I would be interested to hear it, but I suppose I will just have to change compilers. Thanks again!
[snip]
As far as I know, that answer is quite simple. Unless something have changed recently, mingw does not support unicode strings. I would suggest to swith to non-mingw version of gcc.
How goes the difference between replace and ireplace? IIUC MinGW itself is as fully wide-aware as any other gcc, it's libstdc++ which is not under MinGW. Using MinGW with another standard library (STLPort for instance) should make your problems go away.
However, since only one of the two algorithms fail, I wonder at their implementation. Does ireplace use some part of the standard library that replace does not?
Difference is quite clear. The second one is using std::locale. If the standard library is broken, it could explain the behaviour Regards, Pavol.
On 20. 1. 2010 18:41, Doug Swanson wrote:
Thank you so much for your reply! I really appreciate it.
Although I remember reading about this issue at some point in the past, I have used std::wstring under MingW-gcc for quite some time now with no problems. If it were really 100% incompatible I would wish it would give a compilation error! I wonder why it crashes under the 'ireplace' algorithms but not the 'replace' ones -- especially since I remain strictly within Unicode Plane 0 (basic 2-byte characters in UTF-16/UCS-2 which fit in a single wchar_t on Windows).
In any event, if you have any further insight here I would be interested to hear it, but I suppose I will just have to change compilers. Thanks again!
As Brian suggested in another post, you might be able to solve the issue by using a different std library, like STLPort for instance. Regards, Pavol.
participants (3)
-
Brian Ravnsgaard Riis -
Doug Swanson -
Pavol Droba