kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

I think I misspoke when I mentioned UTF-16.  The compile switch just changes the internal representation of wxStrings from UFT-8-encoded char’s to non-UTF-8-encoded w_char_t’s.  This wouldn’t have endian issues, would it?

> On 3 Apr 2019, at 16:15, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> 
> Hi Jeff-
> 
> The major downside to our using UTF-16 is that it is not endian-independent.  Unless we drop support for big-endian platforms, we'll need to handle both cases.  I needn't tell you what a pain that would be.
> 
> Maybe we can just not return wxString references?  Enforce a getter/setter paradigm and pass the object?
> 
> Thoughts?
> -S
> 
> 
> Am 2019-04-03 09:35, schrieb Jeff Young:
>> Jon is currently fighting another wxString multi-threading issue.
>> Having done quite a few of these myself, I feel for him.
>> A lot of them were threaded accesses to globals, so it was easy enough
>> to make the globals std::strings.  However, this one is EDA_TEXT’s
>> m_Text field.  That’s going to be a pretty big change to move to
>> std::string.  And it’s nearly impossible to compartmentalise because
>> returning a const& isn’t really const (iterating over the string will
>> modify the linked-list of iterators, which is where the trouble comes
>> in).
>> What about moving Kicad to UTF16 internally?  (The linked list of
>> iterators is a performance optimisation specifically for UTF8 builds.)
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp