Boost logo

Boost :

Subject: Re: [boost] sqlpp11: SQL for C++
From: Roland Bock (rbock_at_[hidden])
Date: 2013-11-11 10:44:19

On 2013-11-11 16:16, Larry Evans wrote:
> On 11/11/13 09:01, Roland Bock wrote:
>> On 2013-11-11 15:36, Edward Diener 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::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...
>> 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:
> 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:
> 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:

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.



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