My $0.02: Is shifting the whole of kicad to wchar_t (along with all the necessary conversions to/from multibyte for IO) easier than wrapping some globals inside locks for thread-safety? Having dealt with an application that uses ASCII, UTF-16, and UTF-8 in various contexts (my day job), I can say honestly that it’s a bit of a pain in the neck. What would break if these global strings were protected by FCFS locks?
-Brian > On Apr 3, 2019, at 9:35 AM, Jeff Young <[email protected]> wrote: > > 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
