List:MySQL++« Previous MessageNext Message »
From:Jonathan Wakely Date:January 29 2008 12:49am
Subject:Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMAL
View as plain text  
On 28/01/2008, Warren Young <mysqlpp@stripped> wrote:
> Jonathan Wakely wrote:
> > 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
> > };
>
> If MySQL++ were seriously concerned with speed, I'd be fine with this.
> As it is, it introduces a new mechanism to maintain for no practical
> benefit....it is ye olde premature optimization.

I'm fine with the typeinfo conparison, but will just say that
optimisation wasn't the primary purpose of the enum.  Consistency and
a single metafunction to say how to do the conversion (a "conversion
traits" if you like) was my main intention.

> What I really want is a single comparison for "float-like" instead of

hmm, so you want a test based on a type ... the conventional way to do
that in C++ is template metaprogramming  :-)

template <typename T> struct is_float_like{ enum { value=0 }; };
template <> struct is_float_like<float> { enum { value=1 }; };
template <> struct is_float_like<double> { enum { value=1 }; };

easily extensible to other float like types (e.g. long double)

but that's equivalent to what I suggested.  Since you already have a
metafunction for saying how the conversion should be done and since
that's already specialised for float and double, I included it in
there.

Or you could use !std::numeric_limits<T>::is_integer
(the conv_promotion could have been written entirely in terms of
numeric_limits that way)

> > and I hope any increase in
> > runtime or executable size will be insignificant.
>
> Executable size is not one of MySQL++'s design concerns.  Saving the
> programmer effort is its primary goal, and that means trading off speed
> and size.  MySQL++ is for those situations where programmer time
> (including opportunity cost) is a more expensive than the cost in
> additoinal CPU power and code space.  If you need it to be smaller, use
> the C API.  If you need it to be faster, maybe you shouldn't be using
> MySQL at all, let alone MySQL++.

Agreed.  I just felt it would have been remiss of me not to mention
that my version might be bigger and slower.

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