kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #11764
The problems with wxString
1) wx >= 2.9 has these constructors
wxString( const char* )
wxString( std::string )
whereas wx 2.8 does not.
Both offer:
wxString( const char*, wxConvUTF8 );
but this cannot be used in a default "type promotion" situation, this constructor must be
invoked explicitly.
2) The above type promotion constructors treat the input encoding as that of the current
locale, rather than UTF8 assuredly.
The type promotion constructors are important if you want to allow the compiler to promote
an 8 bit string to a wxString for you without special syntax.
3) If you decide to keep 8 bit strings in memory, encoded in the current locale, then
someday when you load a chinese board file, you will not be able to hold those strings in
a deficient 8 bit encoding. (UTF8 is not a deficient 8 bit encoding, some others are.)
The software breaks at that point. This argues for using UTF8 always as the internal 8
bit encoding. But now the above two constructors are broken, since the current locale's
encoding cannot be assumed to be UTF8, even though it often is on linux. You just cannot
assume it.
There are a couple of ways forward:
a) hack up a wx header file and bring that one file into the project so the above
constructors can be made to work the way we want. Compile include search path has our
header file first.
b) define a new 8 bit string typedef or class, e.g. "our8bit_string" so we can have our
own promoting constructor:
wxString( our8bit_string )
How do you add a constructor to a class defined in a library, without taking over one of
their header files?
c) wx keeps the notion of the current locale's encoding scheme in a pointer variable.
See "wxConvCurrent" in here:
http://docs.wxwidgets.org/2.8/wx_mbconvclasses.html
Although it might be possible to temporarily change what it points to, if even
momentarily, this is clumsy. I don't know the consequences of changing wxConvCurrent
pointer, permanently, assuming it is not read only.
d) build the entire wx from source, after patching it.
In summary, I don't see any easy immediate relief from the boat anchor we know as
wxString, even with wx 3.0. But I will continue to think about it.
Dick
Follow ups
References