Home » Blog » 2015 » July » CppCon 2014 sqlpp11, An SQL Library Worthy Of Modern C++--Roland Bock

CppCon 2014 sqlpp11, An SQL Library Worthy Of Modern C++--Roland Bock

By Adrien Hamelin | Jul 27, 2015 11:49 AM | Tags: performance community

Have you registered for CppCon 2015 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

sqlpp11, An SQL Library Worthy Of Modern C++

by Roland Bock

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

SQL and C++ are both strongly typed languages. They should play well together. But most C/C++ interfaces to SQL databases are string based. They force the developer to effectively hide the SQL types, names and expression structures from the compiler. This defers the validation of SQL expressions until runtime, i.e. unit tests or even production. And the strings might even be vendor specific, because different databases expect different dialects of SQL in those strings.

That feels wrong. Modern C++ can do better.

This talk gives an introduction to sqlpp11, a templated embedded domain specific language for SQL in C++. It allows you to build type-safe SQL expressions with type-safe results, all of which can be verified at compile time, long before your code enters unit tests or even production.

In addition to its obvious use with relational databases, sqlpp11 can also serve as an SQL frontend for all kinds of data sources: Since sqlpp11 offers complete SQL expression trees even at compile time, it isn't hard to apply SQL expressions to std::vector or std::map for instance, or streams, or XML, or JSON, you name it. With your help, sqlpp11 could become for C++ what LINQ is for C#.

Add a Comment

Comments are closed.

Comments (1)

0 0

merely useful said on Jul 29, 2015 03:50 AM:

I strongly believe that abstracting SQL away like this is a Really Bad Idea I think Linq, SQLAlchemy and the other frameworks that are used to access SQL databases mostly came about for two reasons: 1 The inability of developers to make changes to databases that are tightly controlled by DBAs and 2 the inability of OO or procedural programmers to really understand how to write set-based code in SQL.

The majority of the code I've seen that uses them attempts to represent the database structure in middleware code when this is absolutely not what a developer should be doing. The database should be optimised for the efficient storage and retrieval of data all tightly controlled in a declarative structure by use of constraints. I always hide this completely from the middleware by accessing the data only though views and stored procedures and then using that data to directly populate the data structures that the middleware needs to manipulate. This rarely looks like the underlying tables.

Accessing postgres for example through the C API in a C++ app is extremely simple, well documented and efficient. Even MSSQL server is perfectly usable by ignoring Linq and pulling the data into native C# structures. Why bother hiding this behind a framework that will not be as efficient as a well structured database, won't match the business requirements of the app and middleware and will require recompilation whenever the DB schema changes?

Neil