[wx-dev] Re: #9672: wx 2.9 Ansi/Unicode Combi-wxString breaks compatibility with std::[w]string and introduces subtle errors

[Hajo Kirchhoff]

Ticket URL: <http://trac.wxwidgets.org/ticket/9672#comment:8>
> #9672: wx 2.9 Ansi/Unicode Combi-wxString breaks compatibility with std::[w]string
> Comment(by neis):
> 
>  Replying to [comment:6 hajokirchhoff]:
>  > > Yes, and nobody uses wchar_t, so please let's just drop this and let's
>  do UTF-8 builds only.
Stefan, the wchar_t discussion is completely besides the point.

The problems I reported exist no matter what character type you are 
using. Replace wchar_t with char, my comments still apply.

The way you are trying to handle both character types in wxString '''at 
the same time''' is '''causing''' the troubles.

Using std::string with 'char', boost::algorithm::istarts_with(wxString, 
std::string) fails for german umlauts.

ofstream::open(wxString) fails to compile on Visual Studio (because open 
is overloaded there accepting char and wchar_t).

wxString::c_str() suddenly no longer returns char* or wchar_t*, but a 
pointer to a wxWidgets datatype. This datatype has two implicit 
conversions to char* and wchar_t*. This breaks template deduction 
because it is no longer clear which conversion should be used.


To get an upgrade of your ANSI-only-applications to Unicode for free you 
break existing code and reduce wxString compatibility with STL and boost 
to zero.

You took one of the most important and fundamental datatypes in 
wxWidgets, wxString, and changed the interface.

I wonder how I am going explain to my software consulting customers, 
that they effectively won't be able to use wxWidgets beyond version 2.8 
because you changed wxString in order to get Ansi->Unicode upgrade for 
free. Debugging their large codebase to find all instances where 
wxString is being used together with stl/boost is prohibitive.

Changing the interface of something so fundamental as wxString should 
not be done, unless it is absolutely backwards compatible. Turns out it 
is not.

Your approach looked good at first, but the devil is in the details and 
it should be rethought.

Perhaps a working approach would be to introduce a new wxStringUTF8, 
which has compatibility interfaces with wxString. Then you could simply 
search and replace all instances of wxString with the new class in your 
application code and have unicode ability. Doing a search and replace is 
several orders less complicated than debugging code that compiles fine 
but does not work as expected under some circumstances.

Best regards

Hajo