10 messages in com.mysql.lists.plusplusRe: Still gettiing a BadConversion th...| From | Sent On | Attachments |
|---|---|---|
| Bart Verstraete | 20 Jan 2008 06:35 | |
| Warren Young | 21 Jan 2008 09:18 | |
| Jonathan Wakely | 21 Jan 2008 10:32 | |
| Warren Young | 21 Jan 2008 10:57 | |
| Jonathan Wakely | 21 Jan 2008 15:58 |  .patch, .patch |
| Jonathan Wakely | 21 Jan 2008 16:34 | |
| Warren Young | 23 Jan 2008 19:50 | |
| Jonathan Wakely | 26 Jan 2008 10:27 | |
| Warren Young | 28 Jan 2008 02:19 | |
| Jonathan Wakely | 28 Jan 2008 16:49 |
| Subject: | Re: Still gettiing a BadConversion thrown with mySQL++ 3.0 RC1 from a DECIMAL |
|---|---|
| From: | Jonathan Wakely (mys...@kayari.org) |
| Date: | 01/28/2008 04:49:17 PM |
| List: | com.mysql.lists.plusplus |
On 28/01/2008, Warren Young <mysq...@etr-usa.com> 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