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