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

[Francois Bertel]

Hello,

I just changed VTK/CMakeLists.txt and
VTK/Common/Testing/Cxx/vtkTestDriver.h to be able to run the C++ tests
under locale conditions.

An advanced flag VTK_TESTING_USE_LOCALE (initial value to OFF) allows
to test the C++ tests with locale.
VTK_TESTING_LOCALE is an advanced string variable (initial value to an
empty string) storing the name of the locale (example: fr_FR.utf8). If
the string is empty it looks at the current environment variables
LC_*, if the string is specified, it
takes it into account, overwriting whatever is in the environment variables.

If VTK_TESTING_USE_LOCALE is ON, the c++ tests start with a call to
the C function setlocale() and with a call to the C++ funtion
std::locale::global().



On Mon, Nov 30, 2009 at 11:08 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>



-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA