Boost logo

Boost :

Subject: Re: [boost] sqlpp11: SQL for C++
From: Abel Sinkovics (abel_at_[hidden])
Date: 2013-11-11 14:35:27

Hi Roland,

On 2013-11-09 23:58, Roland Bock wrote:
> On 2013-11-09 23:03, Michael Marcin wrote:
>> On 11/9/2013 4:03 PM, Roland Bock wrote:
>>> Please let me know your questions/thoughts/suggestions/rants.
>>> Contributions welcome, of course :-)
>> Could you compare your library with SOCI?
> I consider SOCI to be a string and position based approach, meaning that
> you (as a library user) have to use strings to construct your queries
> and positions to extract results. Here is one of SOCI's introductory
> examples:
> // ------------------------
> int id = 17;
> string name;
> int salary;
> sql << "select name, salary from persons where id = " << id,
> into(name), into(salary);
> // ------------------------
> In sqlpp11 this would read something like this
> // ---------------------
> auto result =,
> persons.salary).from(persons).where( == 17));
> if (!result.empty())
> {
> const auto row = result.front();
> std::string name =;
> int salary = row.salary;
> }
> // ---------------------
> Notice that there are no strings being used in the sqlpp11 code at all.
> The compiler can see and check the syntax of your query. If you mistype
> anything, or if you compare apples and oranges (e.g. a text column and
> an int), or if you forget the 'from' before the 'where' for instance, it
> will let you know with compile errors.
> Also, it is much harder to mix up stuff in the results. Imagine a
> slightly larger list of columns being selected. With SOCI you need to
> keep the "select a, b, c, d" in sync with the into(a), into(b), into(c),
> into(d)
> sqlpp11 takes care of this responsibility for you and gives you rows
> with appropriately named and typed member variables. It is much harder
> to use those the wrong way without the compiler yelling at you.
There is a library (Metaparse) which supports creating a string-based
interface for libraries which is processed at compile-time. It could be
used to provide a string-based interface. For example instead of this:

auto result =,
persons.salary).from(persons).where( == 17));

Your library could have the following interface:

auto result ="select name,salary from persons where id=17"));

The string could be parsed by a template metaprogram and the right
classes could be built out of it. It could provide all the static
guarantees you have described above.

The documentation of Metaparse is here:

You can find examples here:


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