kicad-developers team mailing list archive
Mailing list archive
Re: LOCALE_IO thread-local
On 2019-11-08 03:49, jp charras wrote:
Le 21/06/2019 à 23:25, Seth Hillbrand a écrit :
We currently have an RAII locale switch (LOCALE_IO) that swaps the
global locale to allow floating point handling with decimal points
instead of a commas. Because it changes the global locale, we need to
be very careful about allowing the user interface to update during the
time that it is temporarily set.
The attached patch moves the locale setting into a thread-local
allowing us to use standard threading and UI updates.
There are no functionality changes in this patch. This is merely a
change in the calling structure that will allow future cleaning of the
LOCALE_IO distribution in the code.
I'd greatly appreciate any windows testing.
What is the status of this change?
Looks like that one resides in one of my 10k side branches. :)
I had been testing out a few different approaches here. This one (after
moving the std::atomic to thread local as well) or using internal
conversions with std::imbue/std::num_put/std::num_get. I also
considered using wxWidgets' built-in handlers but tying more closely to
this library outside of UI is not a great idea. I also considered
specialized internal functions copied from ruby or python but don't like
the idea of carrying around chunks of untouchable code.
Incidentally, C++17 will include std::to_chars/std::from_chars, which
always converts in 'C' locale. This seems like the best option for the
project long-term. But, of course, we are not yet C++17 and won't be
for a few years.
For now, I'm speed-testing the num_get routines internally. The basic
istringstream is a no-go for performance as loading gets noticeably
slower. num_put/num_get seem to work correctly and be approximately
equivalent speed, so I hope to send around a patch showing them and
removing LOCALE_IO completely.
KiCad Services Corporation
+1 530 302 5483 | +1 212 603 9372