kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/07/2012 11:10 PM, Lorenzo Marcantonio wrote:
> On Mon, May 07, 2012 at 02:25:44PM -0500, Dick Hollenbeck wrote:
>> But I cannot tell you what a wxChar* means THIS MONTH.
>>
>> The best thing the wxWidgets folks could do is to start with this line:
>>
>> typedef std::string wxString
>>
>> and then go fix all the compile errors after that.
>>
>> wxString has served too many masters and its biggest mistake was coming into existence.



That last sentence was not fair of me, since std::string did not exist when wxString was
written.  But I retain my other point of view that wxString is no longer needed, and
wxWidgets could be done with std::string and an elaborate std::string factory class.


With latest wx, wxString is a container holding a std::string holding characters encoded
as UTF8 bytes on linux and OSX.  Windows is unknown.


See:

http://docs.wxwidgets.org/2.9.3/overview_changes_since28.html#overview_changes_unicode

which says:


"For example, the notorious (due to the confusion they created) macros |wxT()
<http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__string.html#ga437ea6ba615b75dac8603e96ec864160>|
and |_T()
<http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__string.html#ga7dfc2888539861afe6c4337ef315472b>|
are not needed at all any longer."


This means that we eventually, we'll no longer need all the wxT() stuff, since we
basically never put anything but ASCII characters in those wrappers and to convert from an
ASCII string to UTF8 is simply a matter of copying bytes without any conversion at all. 
And converting ASCII bytes to UTF16 characters is simply a matter of zeroing out the upper
byte.


So eventually we can go back and remove all the wxT() wrappers.

I think all their APIs would be better off using UTF8 encoded std::strings, they could
convert to any other required encoding behind their public APIs, as they do now from wxString.

wxChar* in such a world, typedef-ed to a pointer to a 32 bit character, should not be
needed much for strings anyways in the future.  Single characters yes, strings not so much.

wxString feels a lot like the 80's and 90's now, which I characterize as "let's watch
Microsoft learn how to program, as they lead us into the future", constantly changing
directions, constantly costing developers money chasing a new fad, zigging left, then
right, but always wanting to lead, not knowing where they are going.


Dick





> The wx wiki *explicitly* tells to use fscking wxString instead of std::string!
> ----
> Note that it is recommended to use wxString as much as possible. Do no use char* or std::string unless you use a third-party library that requires you to do so. 
> ----
>
> Since I didn't passed --disable-unicode, wxChar* should be a wchar_t*. Also the operator const wxChar * is present... maybe the culprit is lacking the const bit somehow.
>
> Also the 'fun' thing in the wx trunk doc is this:
>
> ----
> The wxString class has been completely rewritten for wxWidgets 3.0 and this change was actually the main reason for the calling that version wxWidgets 3.0.
>
> wxString is a class representing a Unicode character string. wxString uses std::basic_string internally (even if wxUSE_STL is not defined) to store its content (unless this is not supported by the compiler or disabled specifically when building wxWidgets) and it therefore inherits many features from std::basic_string. (Note that most implementations of std::basic_string are thread-safe and don't use reference counting.)
> ----
>
> So at least part of your suggestion was taken in account... (I'd rather have junked it wxString completely) also part of the fun is that "wxString USES std::basic_string" not "wxString EXTENDS std::basic_string". Yay a PART-OF instead of IS-A relationship...
>
> I don't actually care about 2.9 at the moment...
>