[wx-dev] RFC: UTF-8 build mode for wx: wxUSE_UNCODE

[Vadim Zeitlin]

On Mon, 26 Feb 2007 22:11:35 +0100 Vaclav Slavik <vslavik at fastmail.fm> wrote:

VS> > 1. Windows Service creation:
VS> >
VS> >   if (newservice) {
VS> >     SERVICE_DESCRIPTION sdBuf;
VS> > #if wxUSE_UNICODE
VS> >     sdBuf.lpDescription = (LPWSTR)wxstrDescription.c_str();
VS> > #else
VS> >     sdBuf.lpDescription = (LPSTR)wxstrDescription.c_str();
VS> > #endif
VS> 
VS> This is definitely a common case :( It's quite frequently done in 
VS> wxMSW code itself and it's causing a problem: Win32 API expects to 
VS> have non-const strings here, but c_str() current returns const 
VS> wxChar*, hence the cast above (it's equivalent to "... = 
VS> (wxChar*)wxstrDesc.c_str();"). But if c_str() returns wxCStrData with 
VS> implicit conversion to const char/wchar_t* only,  then the above code 
VS> would stop compiling and would have to be rewritten as 
VS> 
VS>   (const wxChar*)(wxChar*)wxstrDesc.c_str()

 As 

	(wxChar *)(const wxChar *)wxstrDesc.c_str()

but this doesn't really change anything, of course, it's still ugly.

VS> The solution would be to add (wxChar*) cast to 
VS> wxCStrData (i.e., only to the native char type, not both char* and 
VS> wchar_t*, so that it's cheap and points to valid data). It's not 
VS> nice, but realistically, it's probably the only thing we can do, 
VS> because const-unsafe C APIs are not entirely uncommon. 

 I agree but I still wouldn't make this cast implicit. When you do
something like this, it should really stand out so I'd rather write either

	wxstrDesc.c_str().ConstCast()

or even just

	wxStrConstCast(wxstrDesc)


VS> >     args = wxCmdLineParser::ConvertStringToArgs(cmdLine);
VS> >   //argc = args.GetCount();
VS> >   // +1 here for the terminating NULL
VS> >   wxChar **wargv = new wxChar *[argc + 1];
VS> >   for ( int i = 0; i < argc; i++ )
VS> >     wargv[i] = wxStrdup(args[i]);
VS> 
VS> This breaks under the proposed changes because wxChar is a class. 
VS> Would be easily convertible using a new type -- 
VS> wxNativeCharType(?) -- replacing wxChar for these uses. 

 If we do need such type[def], I think it should be called wxChar_t as this
indicates that it's related to both char and wchar_t.

VS> Alternatively, we could accept wxChar* (i.e. array of wxChar class 
VS> instances) in wx wrappers as well (possibly with performance warning 
VS> logged to debug output). Actually, that's probably the best, because 
VS> it's easily done without affecting other stuff.

 Yes, I agree.

VS> The rest of your examples would compile OK.

 I see at least one other line which would be broken, I'll reply to it in
another mail.

VS> would be better to set wxUSE_UNICODE to 1 here, because you use it to 
VS> enable Unicode-aware code

 Right.

 Regards,
VZ