kicad-developers team mailing list archive

["stambaughw" <stambaughw@...>]

--- 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 codestyle to enhance code longevity and issues tomorrow.
> >>
> >>
> >> Please take a look to:
> >> http://docs.wxwidgets.org/trunk/overview_unicode.html#overview_unicode_pitfalls
> >> http://docs.wxwidgets.org/trunk/classwx_string.html#conv

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 isgoing 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.

Wayne

> >>     
> >
> > Thanks for the info. Looks like we'll have to support the differences
> > between 3.X and 2.8.x strings for the foreseeable future. 
> 
> 
> All the upcoming differences are well hidden in the new APIs except one, 
> the one I identified: wxString::Printf()
> 
> And the best way of future-proofing the usage of wxString::Printf() is 
> to use GetChars().
> 
> I hope this email settles the issue.
> 
> Dick
>