const char* to double translation issue with C++

Question

I have two sample applications using the same library and the main difference between them is that one uses qt and the other application is a console application.

In the common library, I have this test code:

double test = 0.1;
double test2 = atof("2.13134");
double test3 = atof("1,12345");

The values if I use the non-qt application are:

test = 0.10000000000001
test2 = 2.1323399999999999998
test3 = 1   // This is the expected result using a ',' as delimitation character

But with the qt application:

test = 0.10000000000001
test2 = 2     // This is not expected!!!
test3 = 1.1234500000000000001

Is there any case where the behaviour of the 'atof' changes because qt?

Qt uses preprocessing of the code, which might do ungood things. Or there might be some macro at play. — Cheers and hth. - Alf, Feb 09 '16 at 14:53
@Cheersandhth.-Alf This looks more like a locale issue (remember that `,` is the decimal point character in many locales) - perhaps Qt is setting a non-default locale based on system settings? — Angew is no longer proud of SO, Feb 09 '16 at 14:57
The main issue here is, why the decimal point character is different. Because I am not changing this intentionally, and this piece of code is not using qt at all. — goe, Feb 09 '16 at 15:01
@Angew: Thanks I didn't know that `atof` and `strtod` were locale-dependent. That's *horrible*. Until just a few years one *had* to set the C default user locale with g++ in Windows, because the locale support was botched. — Cheers and hth. - Alf, Feb 09 '16 at 15:02
@Cheersandhth.-Alf "Qt uses preprocessing of the code, which might do ungood things." **No**, it might not. That's not how it works. — Kuba hasn't forgotten Monica, Feb 09 '16 at 15:54
@KubaOber: "How usable is Qt without its preprocessing step?" Not very. http://stackoverflow.com/questions/3588154/how-usable-is-qt-without-its-preprocessing-step — Cheers and hth. - Alf, Feb 09 '16 at 15:58
@Cheersandhth.-Alf Again, that's not how it work. You claim that it "might do ungood things" is not based in any reality I'm a part of. — Kuba hasn't forgotten Monica, Feb 09 '16 at 16:10
@KubaOber: Any preprocessing might do ungood things. That's just how it is. Learn to live with it, don't be a fanboy or bigot. — Cheers and hth. - Alf, Feb 09 '16 at 16:18
@Cheersandhth.-Alf moc doesn’t modify existing code, it generates *additional* code for signal/slots, metaobject handling. — Frank Osterfeld, Feb 09 '16 at 18:02

Angew is no longer proud of SO · Accepted Answer · 2016-02-09T15:57:15.027

7

std::atof depends on the currently set locale to tell it which character is the decimal point. In the default case ("C locale"), that is the period character '.'.

It's likely that Qt is setting the locale to something else. You can revert that using the standard C[++] mechanism:

std::setlocale(LC_ALL, "C");

edited Feb 09 '16 at 15:57

answered Feb 09 '16 at 15:02

Angew is no longer proud of SO

167,307
17
350
455

I have included 'std::setlocale(LC_ALL, "C");' in the constructor of the class in the library, and it is working now. Thanks!!! – goe Feb 09 '16 at 15:07
@goe: It might be a good idea to check whether narrow string literals with international characters now end up correctly as Qt strings. – Cheers and hth. - Alf Feb 09 '16 at 15:19

score 4 · Answer 2 · edited May 23 '17 at 11:45

4

The problem you are noticing is most likely caused by Qt's notion of locale. You can use:

QLocale::setDefault(QLocale::C);

to make it work like atof.

Update

It seems QLocale::setDefault does not set the default locale used by Qt. It merely sets the default locale that will be created when you construct a QLocale. See Changing locale in Qt and the accepted answer for more info.

edited May 23 '17 at 11:45

Community

1
1

answered Feb 09 '16 at 14:58

R Sahu

204,454
14
159
270

const char* to double translation issue with C++

2 Answers2