From: Warren Young Date: February 8 2008 2:02am Subject: RFC: What to do about the integer type mess? List-Archive: http://lists.mysql.com/plusplus/7438 Message-Id: <47ABB82F.1090205@etr-usa.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020603020708010809050102" --------------020603020708010809050102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your humble maintainer has been slacking. Only yesterday did I begin trying to convert my company's code to MySQL++ v3. Not exactly eating my own dogfood... This has resulted in several minor changes to the svn version in the past few days, but only one thing has stood out as really problematic so far: integer types aren't being treated very flexibly or portably. There are two problems, really: 1. MySQL++ doesn't support long int in queries or SSQLS any more. If you try, you get an assertion (RC3) or an unconditional exception (next release). If this was the only problem, the fix would be obvious and I wouldn't be bothering the list about it. But, it feeds right into... 2. The typedefs in lib/sql_types.h currently assume a standard 32-bit x86 type system. MySQL defines exactly how many bytes INT is, but C++ doesn't provide the same rigid definition for int, the current type we use for mysqlpp::sql_int. It all works out the same on a 32-bit PC, but 64-bit systems will usually make this 64-bit. Or if they don't, then long int certainly is 64-bit. C99 nailed this problem with stdint.h. It wouldn't be the first time we used a C99 feature in MySQL++ even though C++ doesn't officially support stdint.h yet. So far, though, all use of C99 features has been optional. To make use of stdint.h optional, we'd basically have to reinvent it, not something I'm happy doing since it would be different for every platform. A perfectly good, widespread solution exists, so I'd like to use it. It's something we need to take care of before v3 is released. So, what do you all think? Would the attached patch be a problem? The patch still doesn't let you use long on a 32-bit machine, as it's probably not used in your system's stdint.h. You probably shouldn't be using this data type for portability reasons anyway, as it will change on you. That said, once we figure out the integer sizing problem, a way to use long portably might present itself. For instance, the mysql_type_info::types[] table could use sql_int for long on 32-bit systems, and sql_bigint on 64-bit ones. --------------020603020708010809050102 Content-Type: text/x-patch; name="mysqlpp-stdint.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mysqlpp-stdint.patch" Index: lib/sql_types.h =================================================================== --- lib/sql_types.h (revision 2169) +++ lib/sql_types.h (working copy) @@ -31,6 +31,8 @@ #include +#include + namespace mysqlpp { #if !defined(DOXYGEN_IGNORE) @@ -39,16 +41,16 @@ // Nearest C++ equivalents of MySQL data types. These are only the "NOT // NULL" variants. Wrap these types in MySQL++'s Null<> template to get // NULL-able types. -typedef tiny_int sql_tinyint; -typedef tiny_int sql_tinyint_unsigned; -typedef short sql_smallint; -typedef unsigned short sql_smallint_unsigned; -typedef int sql_int; -typedef unsigned int sql_int_unsigned; -typedef int sql_mediumint; -typedef unsigned int sql_mediumint_unsigned; -typedef longlong sql_bigint; -typedef ulonglong sql_bigint_unsigned; +typedef tiny_int sql_tinyint; +typedef tiny_int sql_tinyint_unsigned; +typedef int16_t sql_smallint; +typedef uint16_t sql_smallint_unsigned; +typedef int32_t sql_int; +typedef uint32_t sql_int_unsigned; +typedef int32_t sql_mediumint; +typedef uint32_t sql_mediumint_unsigned; +typedef int64_t sql_bigint; +typedef uint64_t sql_bigint_unsigned; typedef float sql_float; typedef double sql_double; --------------020603020708010809050102--