Mailing List
Home
Forum Home
MySQL General - General MySQL discussion
MySQL++ - Programming with the C++ API to MySQL
MaxDB - Everything about MaxDB, formerly known as SAP DB
ODBC - ODBC with the MySQL Connector/ODBC driver
MySQL on Win32 - Runing MySQL on Windows 9x/Me/NT/2000/XP
Java Help - Mostly related to the MySQL Connector/J driver
Perl - Perl support for MySQL with DBI and DBD::mysql
GUI - MySQL GUI Tools
Announcement
Subjects
mysql openssl Question
ERROR 1045: Access denied for user: 'root@localhost ' (Using
password: NO)
Update one field with more fields from another table
Getting Identity after INSERT
ERROR 2002: Can 't connect to local MySQL server through socket
mysql test 4 1 fails with the gis test
MySQL Cluster Software
Downgrade Mysql from 4 to 3 23
Mysql 4 0 Oracle Stored Procedure Trigger Conversion
Can 't access mysql after kernel upgrade
Executing MySQL Commands From Within C Program
Comparing and writing out BLOBS
Preventing Duplicate Entries
FULLTEXT query format question
Strange behavior, Table Level Permission
Does the binary log enabling affect the MySQL performances?
mysql:it 's a db not a dbms how it 's possible?!
mysql have same function mthod as Oracle decode()
 
Is anyone using SQLString directly?

Is anyone using SQLString directly?

2007-08-10       - By Warren Young

 Back
SQLString exists for those places where the library wants to let you
pass any typical C/C++ type, which it will convert automatically to a
SQL-compatible string representation.  This is what lets you pass, say,
a mysqlpp::DateTime() to Query::store() to fill in a template query.

MySQL++ currently also provides ColData, which is almost a perfect
inverse: it takes query results in SQL string form, and lets you convert
that easily to typical C/C++ data types.

Do we really need two specialized string types in MySQL++?

The only thing that prevents these two from being complete inverses is
that ColData is purely a constant string, while SQLString derives from
std::string.  SQLString is potentially useful as a general purpose
string type, while ColData only accepts new values through its ctors and
assignment operators.

MySQL++ doesn't need SQLString to be mutable, though, so the only way
this matters is if someone out there is using SQLString in place of
std::string.  Unless that's happening, I can combine these two without
reimplementing std::string or deriving from it.  In fact, it would be an
almost trivial extension of the current implementation of ColData in svn.

I don't see why anyone would care to use SQLString this way, but I've
been surprised before...

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=mysql@(protected)