Boost logo

Boost :

Subject: Re: [boost] sqlpp11: SQL for C++
From: Roland Bock (rbock_at_[hidden])
Date: 2013-11-11 03:36:06

On 2013-11-11 01:47, Larry Evans wrote:
> On 11/10/13 18:02, Larry Evans wrote:
>> On 11/09/13 16:03, Roland Bock wrote:
>>> Hi,
>>> over the last four or five years I developed several SQL libraries for
>>> C++. With C++11 I was finally able to create an SQL library that meets
>>> my own expectations and requirements. It is being used in production, I
>>> recently put it on github, and I would really like to hear from you
>>> guys
>>> whether this is something that could be interesting for you personally
>>> or for boost?
>> [snip]
>> The code here:
>> contains:
>> template<typename Table, typename... ColumnSpec>
>> struct table_base_t
>> : public ColumnSpec::_name_t::template
>> _member_t<column_t<Table, ColumnSpec>>...
>> {...};
>> which looks like it declares a table row, where the columns
>> come from ColumnSpec...

In understanding how the library works, this is probably one of the
crucial parts.
As you guessed correctly, it declares the innards of a table class. The
somewhat convoluted looking inheritance adds columns as members to the
class. The

column_t<Table, ColumnSpec>

instantiates a column class with all required information like the value
type, whether it can be NULL, its textual representation, etc. The
ColumnSpec also contains a template like this:

template<typename T>
struct _member_t
    T foo;

Inheriting from an instance of this template adds a member with the
respective name (foo in this example) to derived class.
Thus, the code you cited adds objects representing columns as
appropriately named members to the table class.

The same technique is used when creating aliases for expressions, using
selects as pseudo tables and constructing result row classes.

>> What's confusing to me is the code here:
>> contains, what I assume are the ColumnSpecs; however,
>> there's no column_t, there's only column_type.
>> Does table_base.h have a typo?
> OOPS. I see it now:

I guess that part of the confusion is due to names. I know that the code
has inconsistent use of _type and _t suffix, which certainly doesn't
help and is on my list of todos. Having column_t and a member class
_column_type is probably also adding to the confusion.

Maybe renaming _column_type to _column_traits_t would be better?

Best regards,


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