sqlpp11-0.35 released

Finally! sqlpp11 now supports date and datetime and can be compiled with MSVC 2015 Update 1.

There are also a bunch of smaller features, like the empty .in() or the case_when() expressions. And of course a bunch of smaller fixes, improved compile time error messages, plus some refactoring to make the library easier to understand.

date and datetime

Based on Howard Hinnant’s wonderful date library, sqlpp11 now supports date and datetime column types. For instance, assuming we had

Then you could do

Compiles with MSVC 2015 Update 1

Thanks to the latest improvements in the Microsoft’s C++ compiler and the relentless efforts by isliser sqlpp11 can now be compiled with MSVC 2015 Update 1!

There are now some workarounds in the code that I want to get rid of asap. Here is a list of the issues that isliser stumbled across while adjusting sqlpp11:

Hoping for the next update, I am watching those bugs 🙂

Compiles with Xcode 7

Less surprising since Xcode 7 is based on clang, but still: Good to know.

Support for case when then else

sqlpp11 now supports expressions like

The expressions of then and else_ have to be of the same type.

Support for empty in()

You can now use in with empty lists, e.g.

Detect non-aggregates in case of GROUP BY

If you group your results via GROUP BY, then selected columns have to be aggregates. Either by being aggregate functions like count() or sum(), or by consisting of group_by expressions.

sqlpp11 now enforces this at compile time.

 

(Almost) Generic Comparison Operator For Structs

Introduction

A simple struct is easy to write. The compiler generates default constructors for us (unless we disturb it). It is readily to be used in vectors and lists, the world is nice.

And then you want to use you shiny new struct as a key in a map. Hmmpf. Need to write a less operator…

OK, so lets assume this is our struct:

Here’s a handcrafted less operator:

This is annoying to write. It is prone to errors while writing it the first time and also when time comes for maintenance (e.g lets add a language and swap title and author).

Macros come to mind, but many people frown on them.

Pointer-to-data-member to the rescue

Pointers to data members look quite weird if you aren’t used to them. But they allow us to specify access to data members of a struct via the pointer-to-member-access operators.

In combination with variadic templates we can write a generic less function that compares structs by data members with a given precedence.

m and rest sure look a bit crazy, being mixed with T, but they get the job done. They are used to iterate through a given order of data members.

And this is how we can use it to compare Talk objects:

This is nice and simple again, suiting a simple struct 🙂

 

 

Dreaming of Names

Lets take a look at a simple struct:

Ok, that is simple. A struct with a member

  • type int
  • default value 42
  • called id

Lets suppose we want to make this compile-time configurable. Well, you think, this is still simple, and you probably have something like this in mind:

Now this template has a member of

  • configurable type
  • configurable default value

But the member is still called id and there is nothing you can do to make this configurable (unless you are into preprocessor macros)

This is driving me nuts because I really need configurable names for sqlpp11 and it is such an effort to this kind of stuff today (using variadic inheritance to create tables an result rows with appropriately typed and named data members).

The feedback I received for a workshop at CppCon 2014 and a talk at the Munich C++ Meetup tells me that others have similar needs.

Dreaming

I would really like to be able to write a template like this:

And then use it in the following way for instance:

Just lean back and think about it for a moment. Being able to have names as template parameters? Why would that be useful?

Here are some ideas:

Named Tuples

Tuples are great for generic programming. But for library interfaces? Not always. Sometimes you’re just too lazy to write a struct with 5 elements and to define comparison operators. And you leave it up to the user of the library to use std::tie or std::get to access the tuple members.

How about you could define tuples that have directly accessible data members with reasonable names?

Assuming we can use names as template parameters, lets define a small helper:

Then we could define a named tuple just like that:

And then use it like this, for example:

So now we have a tuple that has appropriately typed and named members. In non-generic contexts, this is so much nicer to use.

Admittedly, I omitted a few details. Like constructors or the comparison operators, for instance. As an example, here is what a less operator for named tuples could look like.

(By the way, this is pretty close to the first target use case of the SG7 call for papers: Generating equality operators)

How about std::get or std::tie or whatnot? I leave that to you 🙂

Replacing CRTP

CRTP (Curiously recurring template pattern) always feels weird to me. I use it, but it feels weird.

Here is an example that works today:

Admittedly, this is even worse than most introductory examples, since the derived struct is parametrized with the base template instead of a base class. But it is still much simpler than what I use in sqlpp11, where I have a variadic form of this.

Anyway, using CRTP, you can define certain bits of functionality once and then add them to one or more derived classes.

Cool. This actually works.

Wait, what? Cool? Seriously? It gives me the creeps!

  • Public inheritance without a real “IsA” relationship, and Sean Parent said that inheritance is the base class of evil, didn’t he?
  • The typical static cast to the derived class is just gross.
  • The order of instantiation requires the base class often to use TMP tricks to access information from the derived class.
  • And try to do that with a variadic number of CRTP bases, it works, but it is ugly.

Could we do better?

If we could reason about names, as described above, yes, we could! Here’s the idea:

What happens here? The mixin struct defines a name (check).  It is then instantiated in MyClass using this name. MyClass now has a callable member called check.

This approach is so much simpler:

  • There is no inheritance involved
  • There is no need to statically cast oneself to a derived thing
  • Even having a variadic number of mixins does not make the whole thing harder to grok.

Admittedly, there is also a drawback: Each mixin requires to store the pointer to the object it is used in. This approach is therefore certainly not suited for all situations.

The Struct-of-Arrays vector

Another (incomplete) usecase of names would be type transformations based on reflection. Say we had a struct

We want to create a struct of arrays from it (see SG7 Call for papers) and some reflection capability identifies the name of the data members, then we could simply use the following StructOfArrays template:

Like this:

And of course

Libraries like sqlpp11 would greatly benefit from being able to reason about names. Tables, columns and result fields all have names. And these names are being used by the users of the library (not as strings, but as real C++ names). Tables and SQL statements are represented by variadic CRTP constructs. This could be so much simpler if we could use names as described above.

And with reflection, it would be relatively simple to use SQL on C++ data structures or streams. A proof of concept is shown here, but it won’t really fly before we have both reflection and names.

Summary

Pretty much on day one, every programmer learns about the value of using good names. Still, all of C++’s TMP revolves about types and values.

I would really like to be able to reason about names in C++ at compile time as described above.

Let me know, what you think 🙂

sqlpp11-0.30 released

This is the first release of sqlpp11 since early October and the library has undergone quite a few changes. Some of those are listed below:

Functional Changes:

  • Preprocessor generator for columns/tables. Thanks niXman!
  • Added custom query command. This allows you to combine building blocks of sqlpp11 into custom queries, for instance a SELECT..INTO:
  • Added UNION clause
  • Added WITH clause and Common Table Expressions
  • Better understanding of names by the library. Any two entities (e.g. columns) with the same name, now also share a common type representing this name, see also section “Migration”. This leads to more stringent compile time tests.

The documentation for those major changes and a few minor additions will follow in the Wiki over the next few weeks. Until then, the tests and examples from the repository will have to do 🙂

Misc:

  • Less lengthy template error messages. Applying the techniques shown in the talk mentioned above reduced the amount of error messages a lot.
  • Warning free compilation even with -Wconversion, -Wpedantic and -Wshadow, thanks TyRoXx!

Caveat:

    Attempting to compile sqlpp11 with clang-3.1 crashes the compiler.

Migration:

If you are using an older version of sqlpp11,  you will have to update your code generator.  This is what a new column looks like

Here’s an old version for comparison:

Switching to the preprocessor code (see above) might also be an option.