Re: [boost] sqlpp11: SQL for C++

Subject: Re: [boost] sqlpp11: SQL for C++
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-11-11 16:22:24

On 11/11/2013 10:01 AM, Roland Bock wrote:
> On 2013-11-11 15:36, Edward Diener wrote:
>> On 11/11/2013 7:53 AM, Roland Bock wrote:
>>> On 2013-11-11 11:27, Rodrigo Madera wrote:
>>>> On Sat, Nov 9, 2013 at 8:03 PM, Roland Bock <rbock_at_[hidden]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>> Hello,
>>>>
>>>> Just curious over some points:
>>>>
>>>> Does it support binary transfers over the wire?
>>> The library creates template expression trees for the queries. As of
>>> now, the tree is serialized and sent to the database connector when you
>>> call
>>>
>>> db.run(query)
>>>
>>> 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::vector<std::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
> 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...

It is irrelevant what the database client libraries return. If you are 
designing an intelligent interface for C++ end-users to use I believe 
you should create a return of data which is converted into some C++ data 
type(s). If the returned data is an array of pointers to something lets 
have it converted, at compile time or run-time, depending on how your 
library works, into data which a C++ end-user can understand. I do not 
view 'char **' as anything I want to deal with in modern C++, no matter 
what it is supposed to mean.

With that said the idea of your library looks very interesting. I have 
always favored an SQL C++ library as one dealing with SQL syntaxes as 
templated C++ constructs via a DSEL rather than SQL strings of 
statements. The only downside to your library is that on-the-fly SQL 
queries based on run-time analysis of database table structure is 
impossible with such a design, so that I would suggest you also provide 
a way of generating an SQL string at run-time as a query, with all 
syntax checking of the string as an end-user responsibility.