kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 11/21/2013 3:16 PM, Dick Hollenbeck wrote:
> 
> 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
> 

Thanks for the information.  It definitely sheds more light on the
issues.  Given some of the choices above, it doesn't look like there
will be a painless solution.  I wonder if we could derive our own string
class from wxString and overload all of the constructors and add any
missing ones to always construct the string using wxConvUTF8.  The only
drawback with this method would be if you ever want to use a non-UTF8
string for some reason.