On 12/27/2013 11:02, Jake Colman wrote:
> My former developer added a new method to type_info.h:
C++ code that makes explicit decisions based on the type of variables is
usually weak or broken in some way. Casts are similarly a bad sign.
If you can rewrite this code to avoid the explicit tests or casts, it's
probably going to be an improvement.
MySQL++ keeps DB values in the String type up to the point where you use
a C++ automatic conversion, whereupon it does its best to convert the
string data into the destination type. If you're using SSQLS, this
magic happens automatically.
The only reason I can think of that you might *need* explicit type
awareness is if your app doesn't know the DB schema in advance, and has
to figure it out by using MySQL++ as a kind of reflection mechanism.
If you always know your column data types in advance -- as is sensible
when using a statically-typed language like C++ -- you should be using
MySQL++'s built in automatic conversions.
> The point of this method is to allow for getting at the MYSQL_TYPE_XXXX
If you really must do explicit type testing, it's much better to do it
via Result::field_type() or String::type(). (String::type() is
available indirectly via constructions like row[i].type().)
Realize that all three of these methods -- the two just mentioned, plus
your home-grown alternative -- poke holes in the MySQL++ abstraction.
You don't get to complain when the abstraction leaks on you.
Specifically here, if MySQL++ ever does become DB independent, these
mechanisms you're using will necessarily change, breaking the code
you're writing that digs below MySQL++ to the MySQL C API level.