[Gdal-dev] locale handling in GDAL

[Kirk McKelvey]

For our SDK and apps, we too are using a scoped locale-changing object
similar to what Frank describes.  In every method or function where we
call a GDAL function or create a GDAL object we are overriding the
locale.

This has not been our preferred solution since this policy would have
had to be integrated into our coding practices if future wkt-parsing
problems were to be avoided.  So that is one vote in favor of GDAL
setting the locale internally.

On the other hand, we have gotten bitten with similar workarounds in the
past.  When using setlocale() in tight loops performance would go
through the floor; apparently it is not a cheap operation.  So if GDAL
sets locale internally then I have no way to mitigate the performance
issues that will come up from calling GDAL functions in tight loops.  So
that is one vote against GDAL setting the locale internally.

Ideally GDAL would *not* fiddle with the locale.  Instead it would only
use locale-sensitive functions when dealing with strings that are in the
locale (mainly user input and output), and "something else" when dealing
with strings that are well-defined and not locale-specific (viz. WKT).
But what is that "something else"?  An atof() replacement would be
doable (if tedious), but printf() would be a major pain to replace...

-Kirk


> -----Original Message-----
> From: gdal-dev-bounces at lists.maptools.org 
> [mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Ben Discoe
> Sent: Saturday, March 04, 2006 1:41 AM
> To: 'gdal-dev'
> Subject: RE: [Gdal-dev] locale handling in GDAL
> 
> > -----Original Message-----
> > From: Frank Warmerdam
> > 
> > Peng Gao has pointed out that GDAL can fall over rather 
> ungracefully 
> > if used in a locale with odd numeric formatting rules, such as many 
> > European locales.
> > 
> > For instance, in the Danish locale printf( "%g\n", 1.234) 
> will produce 
> > "1,234"
> 
> Indeed; in fact, the issue is not just internal to GDAL, but 
> also in user code built on it, which e.g. might call atof on 
> a field value returned by OGR.  So developers should be aware 
> that they need to consider it this themselves, not just 
> expect a library to take care of it for them.
> 
> OGRSpatialReference is especially sensitive.  Nearly every 
> method will fail badly with Euro locale, as they atof/ftoa heavily.
> 
> > [...] I implemented this using a small class declared in cpl_conv.h 
> > called CPLLocaleC.  When created, objects of this class will force 
> > LC_NUMERIC to C.
> > When destroyed they will restore the
> > original locale setting.
> 
> Interesting, i did the same thing years ago (VTP's is called 
> LocaleWrap) and declare it in each scope which calls 
> GDAL/OGR, as needed.
> 
> > I have introduced it's use into GDALOpen, GDALCreate, 
> GDALCreateCopy 
> > and GDALClose.  *Most* parsing and formatting for disk access takes 
> > place in these functions
> 
> If you want to get serious about this, OGRSpatialReference 
> would be the next place to look.  Otherwise, you could just 
> expose and document CPLLocaleC so that developers can take on 
> the responsibility themselves.  That way they can minimize 
> the overhead.
> 
> > BTW, I have also introduced a --locale commandlnie option 
> in the GDAL 
> > standard command line option process
> 
> Interesting, i did the same thing a while back with a 
> -locale=xx command line option :)
> 
> -Ben
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>