On 24/01/2008, Warren Young wrote:
> Jonathan Wakely wrote:
> >
> > It looks to me as though mysqld will always use '.' as the radix
> > character.
>
> Okay, good to know.
>
> But does this not call into question the whole premise behind this
> thread, which is that MySQL++ isn't handling floating-point conversion
> correctly? With this patch, aren't we more or less right back to where
> we were, functionally speaking?
Except now the new tests using an alternative locale pass, and they
failed before. I hope it will also fix Bart's BadConversion
exception.
I hope everything _else_ is functionally equivalent, with that one enhancement.
> > The attached patch to test/string.cpp will reproduce the error.
>
> You might take a look at my new test/string.cpp. It goes to rather
> greater lengths than yours to check things. It all passes, so it is
> ipso facto correct. >:)
Cool, my other tests for edge cases passed too. I like your addition
of checking the type isn't float or double. You could avoid the
typeid() calls by adding a constant to the conv_promotion type:
template<blah blah>
struct conv_promotion
{
typedef blah type;
enum { allow_trailing_zeros = 1 }; // 0 for float/double
};
Then just check it's value in do_conv instead of comparing std::typeinfos.
> > The second patch for mystring.h demonstrates one way to fix it using a
> > stringstream and a std::locale.
>
> Works for me. Applied.
>
> It made my brain explode, but after gathering the pieces back up and
> reassembling it, I found I liked it better than the old macro/template
> hybrid stuff.
Glad you agree. I hope you'll find it more maintainable know that
you've grokked it, I think it's simpler and I hope any increase in
runtime or executable size will be insignificant.
> > (I'm pretty sure) preserves all the side-effects of the
> > strtol/strtoul conversions, such as allowing "42" to convert to
> > char(42) or "257" to silently overflow a char (both of which the
> > stream would handle differently by default.)
>
> Thank you for preserving the current behavior; I like it. I guess we
> could throw BadConversion when exceeding the range of a type, but it
> goes against all expectation.
Agreed, I think the current behaviour is more useful in mysql++'s case.
Besides, it was quite fun coming up with the templates to make it work!
Jon
