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

[Marcus D. Hanwell]

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