← Back to team overview

kicad-developers team mailing list archive

Re: More wxString multi-threading issues


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?


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

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

Follow ups