send2vinnie / pugixml

Automatically exported from code.google.com/p/pugixml
0 stars 0 forks source link

Support decimal separator for number in some non-english languages. #196

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Some languages uses as decimal separator a 'comma' instead of a 'point'.
    English: 3.567
    Spanish: 3,567

You can configure your application to work in Spanish with:
    setlocale(LC_NUMERIC, "es.ES");

From this point onward all conversions from number to string and viceversa will 
assume that the decimal separator is a 'comma'.

If you try to parse an XPath expression like "//Result[1]/@Value + 1,5", you 
will get an error. Pugixml assumes that the decimal separator is always a 
'point'. And this 'point' is hard coded. It would be great if this decimal 
separator could be got from the locale configuration.

A simple way to get automatically the decimal separator character is:

    char find_decimal_separator()
    {
        char str[5];
        sprintf(str, "%g", (double)0.25);
        return str[1];
    }

Original issue reported on code.google.com by fer.fmat...@gmail.com on 11 Feb 2013 at 10:05

Attachments:

GoogleCodeExporter commented 9 years ago
The root of the problem is that XPath specification does not treat numbers as 
locale-specific (so your request, while convenient in practice, violates 
specification).
Introducing this feature silently will potentially break existing uses. And 
there is currently no support for customizing query compilation (even if there 
was, you'd have to use the new flag everywhere).
Finally, I'm reluctant to add yet another #define for this...

I'll think if I can introduce this feature without too many 
interface/configuration changes.

Original comment by arseny.k...@gmail.com on 6 Mar 2013 at 4:18

GoogleCodeExporter commented 9 years ago
Unfortunately, there does not seem to be a good enough way to implement this as 
an extra option. Also, in addition to other mentioned problems, this introduces 
extra parsing ambiguities, i.e. substring("a",1,2) will be parsed in the 
different way.

To summarize, the change is too problematic to be worth it.

Original comment by arseny.k...@gmail.com on 10 Jul 2013 at 5:45