List:MySQL++« Previous MessageNext Message »
From:Jonathan Wakely Date:January 26 2008 6:28pm
Subject:Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMAL
View as plain text  
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
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