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... > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
