[vtkusers] [Insight-developers] wx/vtk weirdness

[Bill Lorensen]

I've already made a pass through the itk readers. Several were broken
wrt locale.

I used a combination of C++ and C locale api's. I encapsulated the C
locale in and itk::Locale class.

I have not checked in any changes yet, but I went from over 40 failing
I/O tests down to 0.

Bill

On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>> Luis,
>>
>> Actually, we can surround certain functions with c-style setlocale and
>> it solves the problems. I already fixed StimulateImageIO,
>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>> any changes yet. Still more investigation is needed as to the best
>> portable solution.
>>
>> I do this:
>>   const char *originalLocale;
>>   char *currentLocale;
>>   originalLocale = setlocale(LC_NUMERIC, NULL);
>>   currentLocale = strdup(originalLocale ? originalLocale : "C");
>>   setlocale(LC_NUMERIC, "C");
>>
>> ......
>>
>>
>> setlocale(LC_NUMERIC, currentLocale);
>>         free(currentLocale);
>
> A page from the Apache C++ resource site gives some good explanations of why
> the C++ locale should be preferred. Mainly because the C locale is a global
> resource, whereas in the C++ locale instances of the locale can be created.
>
> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>
>> For example in StimulateImageIO I surrounded the calls in
>> StimulateImageIO::InternalReadImageInformation with the above
>> snippets.
>>
>> There are other readers/writers that use C++ streams, and there we
>> will have to imbue.
>
> I think that using the C locale is probably the easiest short term solution,
> but to support GUIs using different locales we should be using the C++ locale
> class and associated API. Otherwise users of our libraries may suffer from
> subtle bugs if reading and writing files in separate threads that are all
> using C locales.
>>
>> Even in some code that uses streams, people still use sscanf, atof,
>> etc. In the long run we probably should address these cases with
>> stream replacements.
>
> We should aim to ensure new code uses C++ streams and imbue, and replace
> existing code with C++ streams. As you say this should probably be part of a
> larger i18n effort which would involve using Unicode strings and other changes
> to our libraries.
>
> Marcus
>