← Back to team overview

kicad-developers team mailing list archive

Re: Re: wxString.c_str()


stambaughw wrote:
--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:

Wayne Stambaugh wrote:

emmedics4 wrote:

--- In kicad-devel@xxxxxxxxxxxxxxx, Wayne Stambaugh <stambaughw@>

Has anyone tried using the (const wxChar *) cast operator? I've been
using it in Printf and the logging function calls and it appears to work
fine. It is just a typedef for wxString::const_pointer but it returns
the correct character type depending on the character set used in
wxWidgets. I like it because it is reasonably descriptive and it
appears to work with most versions of wxWidgets. Using the example
above, it is used as follows:

s.Printf( wxT( "%s" ), (const wxChar*) formatMe );

It also works with the gettext _() macro.

Indeed but wxChar is going to be wiped in new versions, i think Dick was talking taking in consideration a more long term approach: changing code style to enhance code longevity and issues tomorrow.

Please take a look to:

I did not read anywhere in these two links that wxChar is going away just that it's behavior is changing. In <http://docs.wxwidgets.org/trunk/overview_changes_since28.html#overview_changes_unicode>, I found this: "You also don't need to use wxChar any longer but can directly use the standard wchar_t type even if, again, wxChar continues to work". So I'm not sure what to think at this point. I'm going to work under the assumption that wxChar is going away which raises another problem. A quick grep of the code will show a lot of places where wxChar* is used a function parameter, function return value, or a variable. If wxChar goes away, then all this code will break. I will change wxChar* to wxString& as I find them.


wxChar* is a pointer to an 8 bit char or to a 16 bit char, and this depends on how wxWidgets is compiled. So it cannot "go away". However, there will be a 3rd way to compile wxWidgets, and that is UTF8. In such as case the wxStrings will store 8 bit characters internally, but encoded as UTF8. This is why the introduced an intermediate object to decode the UTF8 and allow you to get to the unicode characters after they have been decoded.

I don't know the context of your concerns. We should be speaking about specific examples of usage in our code to stay on the same page.

The only case I was concerned about was passing a wxstring to the wxString.Printf() function and we now have that covered with GetChars().