Boost logo

Boost :

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
>>> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at