--------------030805020904050407050307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Version 1.7.40

diffrent use of the second template parameter in parsed_nums

--
Jürgen MF Gleiss

GLEISS & LEEB GESELLSCHAFT M. B. H.
H. Schneidmadlstraße 15, 1.02
3107 St. Pölten

Tel.: +43 (0)676 / 6669644
Fax: +43 (0)2742 / 9001 - 7124
eMail: office (AT) gleiss-leeb (DOT) at



--------------030805020904050407050307
Content-Type: text/plain;
name="patch_sql_query.h_1.7.40"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch_sql_query.h_1.7.40"

--- mysql++-1.7.40/lib/sql_query.h 2005-05-26 16:12:00.000000000 +0200
+++ mysql++-1.7.40_jg/lib/sql_query.h 2005-06-11 16:30:56.000000000 +0200
@@ -328,7 +328,7 @@
std::vector<std::string> parsed_names;

/// \brief Maps template parameter names to their position value.
- std::map<std::string, int> parsed_nums;
+ std::map<std::string, long int> parsed_nums;

typedef const SQLString& ss; ///< to keep parameters lists short
typedef SQLQueryParms parms; ///< abstraction; remove when Query and SQLQuery merge



--------------030805020904050407050307
Content-Type: text/plain; charset=us-ascii


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw
--------------030805020904050407050307--

Jürgen MF Gleiss wrote:
Whenever sending a patch, please also send an explanation of why you
think it is necessary or helpful.

In this case, I think you'd be hard-pressed to find a good explanation.
The only reason I can see in the code why you'd want this is that
variable 'n' in Query:arse() (SQLQuery:arse() in v1.7) is a long
int, so it's not the same size as in the parsed_names instance on 64-bit
systems. But I don't think you can seriously argue that this actually
_needs_ to be a 64-bit integer. It's the position number of the query
parameter; if anything, it should be smaller, not larger!

I believe the proper fix is to change 'n' to a regular int. You could
also argue for a short int, or even a char, but I think that's a silly
optimization.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw