On 21/01/2008, Warren Young wrote:
> Bart Verstraete wrote:
> >
> > is it because mysql++ search a "," and not a "."
>
> Actually, it may be the opposite: MySQL++ currently assumes the decimal
> point is '.', but it's ',' in your country, right? I've just checked in
> a change which will make it look for the decimal point setting in your C
> locale and only fall back to the hard-coded '.' value if that fails.
What is the code in String::conv() for? is it handling the case where
a non-integral value such as "1.000" is converted to an integral type?
For cases where the conversion target is float or double the whole
string should already have been converted by strtod, using the
program's locale setting.
> Please let me know whether this fixes your issue or not.
If the value being converted is "629.2000" then it will still fail,
because the sequence after the decimal point isn't all zeros.
Maybe the program's locale uses ',' and so strtod expects that, but
the column data from MySQL do not use the same setting. This would
mean strtod will always stop converting at the decimal point, and even
if String::conv() uses the same decimal point as MySQL it will throw
if the following characters are not all zero.
If this is what's happening, the program and MySQL need to agree on
the locale used for formatting decimals.
I suspect this could only be handled by mysql++ if it detected the
locale being used by MySQL and used that locale (rather than the
program's global locale) when converting the column data. I don't
remember how to find out the locale MySQL is using, but the
String::conv code could do the conversions using a stringstream imbued
with a std::locale object that matches the MySQL locale.
Also,
if (*end != '\0' && end != 0) {
The second test here is redundant since `end' has already been
dereferenced twice.
Jon
