From: Warren Young Date: January 21 2008 6:58pm Subject: Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMAL List-Archive: http://lists.mysql.com/plusplus/7397 Message-Id: <4794EB4D.3060404@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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.