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.
What I really want is a single comparison for "float-like" instead of
having to make two comparisons, and I want to be able to do it using
nothing other than what's already in the language. Two comparisons now,
that is, and more later if someone gets around to providing a
sql_decimal type, and who knows what else later.
What I really want is duck typing. Waaaah.
> I hope you'll find it more maintainable
Wouldn't have accepted it if I didn't.
> I think it's simpler
It's kind of a toss-up, for me at least. Templates vs. macros...so
similar, and so much potential for confusion and damage with either.
What swung me is the increased control we'll have with this system. If
we need to change the way one type behaves, we're no longer stuck with
the limitations of the strtoX() interface.
> 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++.
