Author: wyoung
Date: Wed Jun 27 09:29:23 2007
New Revision: 1617
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=1617&view=rev
Log:
Added a section to the tquery chapter dealing with potential problems
with function overloading interfering with tquery parameter passing.
Modified:
trunk/doc/userman/userman.dbx
Modified: trunk/doc/userman/userman.dbx
URL:
http://svn.gna.org/viewcvs/mysqlpp/trunk/doc/userman/userman.dbx?rev=1617&r1=1616&r2=1617&view=diff
==============================================================================
--- trunk/doc/userman/userman.dbx (original)
+++ trunk/doc/userman/userman.dbx Wed Jun 27 09:29:23 2007
@@ -1056,8 +1056,9 @@
a query simply use <methodname>Query::store(const
SQLString &parm0, [..., const SQLString
&parm11])</methodname>. This type of multiple overload
- also exists for <methodname>Query::use()</methodname>
- and <methodname>Query::execute()</methodname>. 'parm0'
+ also exists for <methodname>Query::storein()</methodname>,
+ <methodname>Query::use()</methodname> and
+ <methodname>Query::execute()</methodname>. 'parm0'
corresponds to the first parameter, etc. You may specify up
to 25 parameters. For example:</para>
@@ -1079,6 +1080,45 @@
<para>...will become apparent shortly.</para>
</sect2>
+
+ <sect2>
+ <title>Parameter Types and Function Overloads</title>
+
+ <para>There are quite a few overloads for each of
+ <classname>Query</classname>'s query execution
+ functions. (<methodname>store()</methodname>,
+ <methodname>use()</methodname>,
+ <methodname>execute()</methodname>...) It's possible to
+ have code that looks like it should work, but which doesn't,
+ because it's calling the wrong overload. For instance:</para>
+
+ <programlisting>
+query.storein(my_vector, "1");
+query.storein(my_vector, 1);</programlisting>
+
+ <para>The first one works, and the second does
+ not. The cause is a vestigial second parameter to one
+ of <methodname>storein()</methodname>'s overloads that's
+ compatible with integers. Being vestigial, it's only getting
+ in the way right now, but we can't fix it until the next
+ major version of the libary, where it will be okay to break
+ the ABI. Until then, we're stuck with it.</para>
+
+ <para>If the MySQL server keeps rejecting your template
+ queries, try explicitly casting the parameters to
+ <classname>SQLString</classname>:</para>
+
+ <programlisting>
+query.storein(my_vector, SQLString(1));</programlisting>
+
+ <para>This ensures that your code calls one of the overloads
+ meant to handle template query parameters. I don't recommend
+ doing this habitually, because it will clutter your code. For
+ the most part, MySQL++'s interface is set up to do the right
+ thing. It's just that there are still a few corner cases
+ that can't be fixed until the next time we can redesign the
+ interface.</para>
+ </sect2>
<sect2>
<title>Using defaults</title>
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
