Re[2]: [lmi] patch: compilation fix for wx 2.9

[Vadim Zeitlin]

On Sat, 15 May 2010 14:23:37 +0200 Vaclav Slavik <address@hidden> wrote:

[We really should coordinate our replies better... Greg, please don't be
 confused by getting too similar replies, they were written quite
 independently. And sorry for cc'ing the previous one to you one extra
 time, too]

VS> Using mb_str() doesn't introduce any new issues.
...
VS> Put another way, in LMI's case, c_str() is implicit conversion to char*
VS> while mb_str() is explicit.

 You arguably explained it better than me though. The above is really all
that needs to be said.

VS> >  - MinGW gcc, IIRC, doesn't support wide strings, at least not for
VS> >    gcc-3.x (which is what we still use for production). 
VS> 
VS> I'm not aware of such limitations. Looking at Poedit VCS history, its
VS> version 1.3.5 required Unicode build of wx and was compiled with MinGW
VS> 3.4.

 MinGW 3.x console IO doesn't support Unicode AFAIK. But this is not the
main problem, it's the lack of support for Unicode file names in
std::fstream (and lack of extensions in GNU C++ library to remedy this)
that is. IOW we can support Unicode file names with MinGW, of course. But
only using wx and not std::fstream.

VS> > Can we make the diagnostics say something more than
VS> >   Unable to save ''.
VS> 
VS> Yes, by either using wide strings for warnings, or by formatting
VS> filenames specially before passing them to operator<< (e.g. by doing a
VS> custom conversion that replaces unconvertible characters with '?').

 If we refuse to accept the non-ASCII file names at wxFileDialog level
(i.e. in wx code) we can use the usual wxLogError() or wxMessageBox() to
report the errors without any problem (in wx3).

 Regards,
VZ