On 2013-11-11 16:16, Larry Evans wrote:
On 11/11/13 09:01, Roland Bock wrote:
On 11/11/2013 7:53 AM, Roland Bock wrote: [snip]
Result rows are currently to be returned from the connector's result object as const char**, see database_api/api.h.
You are kidding ? Is std::vectorstd::string too advanced ? Why C++ programmers are still using C null-terminated strings I will never understand. No kidding. The database client libraries I've used so far are C
On 2013-11-11 15:36, Edward Diener wrote: libraries yielding char**. That is why the current connector interface also uses const char**. BTW: These are typically not null-terminated but are delivered with a size_t* or similar to inform about the length...
But:
1. As a user of the library you don't get in touch with those. The members of a row are NOT char*, of course. You get integers as integers, floats as floats and of course you get text as std::string. I wouldn't dare to use char* there ;-)
Since the return values from the database are char**, these must be parsed and converted into a vector of, for example, TabSample, where TabSample is from:
https://github.com/rbock/sqlpp11/blob/master/tests/TabSample.h
Sounds like a job for spirit. However, I guess this option was rejected for reasons similar to why proto was rejected for creating the sql string to the dbms, as expressed in your reply to my other post:
http://article.gmane.org/gmane.comp.lib.boost.devel/246117
Is that right?
First, the result is not a sequence of TabSample. The result row type is created based on what you select. That could be analogous to TabSample's rows, but you could select fewer or more columns or different orders... The current status is that the members of the result row parse "their" part of the char**, based on the position and the type of the selected column, see for instance: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/integral.h Look for struct _result_entry_t, currently at line 51. There are respective classes for floating_point, text and bool. These classes could certainly be optimized. Spirit might be able to help here, but yes, you are right, I fear the compile times. In our code base we have hundreds of queries to compile. So compile time is an issue for continuous integration. Regards, Roland