kicad-developers team mailing list archive
Mailing list archive
Re: More wxString multi-threading issues
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
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