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
