List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:January 21 2008 6:58pm
Subject:Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from
a DECIMAL
View as plain text  
Jonathan Wakely wrote:
> 
> What is the code in String::conv() for?

There needs to be an overload of conv() for every type we support.  The 
template form of conv() simply rolls up all the numeric types because 
through internal_string_to_number_proxy, all numerics look sufficiently 
alike.

> If the value being converted is "629.2000" then it will still fail,
> because the sequence after the decimal point isn't all zeros.

No, because *end will be null, because strtod() should consume all 
characters in the string.  And if it isn't, there's a locale mismatch 
because it's getting stuck on the period, which then triggers conv()'s 
"this is not an integer" check.

> Maybe the program's locale uses ',' and so strtod expects that, but
> the column data from MySQL do not use the same setting.

Likely.

> If this is what's happening, the program and MySQL need to agree on
> the locale used for formatting decimals.

Yup.

> 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.

Maybe.  We already hold type info from the DB, so maybe we can pull 
locale info, too.  I'd rather see if we can get by with just C locale 
info first, though, before getting fancy.

>    if (*end != '\0' && end != 0) {
> The second test here is redundant since `end' has already been
> dereferenced twice.

Good catch.  I don't suppose there's any reason to believe strtod() or 
strtol() and friends will actually return a null pointer, so we do want 
to remove it, not move the test up above the first dereference.
Thread
Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 froma DECIMALBart Verstraete20 Jan
  • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 froma DECIMALWarren Young21 Jan
    • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMALJonathan Wakely21 Jan
      • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 froma DECIMALWarren Young21 Jan
        • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMALJonathan Wakely22 Jan
          • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMALJonathan Wakely22 Jan
          • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 froma DECIMALWarren Young24 Jan
            • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMALJonathan Wakely26 Jan
              • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 froma DECIMALWarren Young28 Jan
                • Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMALJonathan Wakely29 Jan