...

Query<string,int> insert_thing(db, "insert into things(name,qty) values ($1,$2)"); SingletonQuery<int, string> count_things(db, "select sum(qty) from things where name=$1");

insert_thing("table",1); insert_thing("chair",4); int n_pens = count_things("pen");

I'd say that your interface is another use case for variadic templates.

Agreed absolutely.

http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html

How many columns can Query support?

I first wrote it with 3, and then hacked it to use the Boost preprocessor library so you can set a preprocessor symbol to define how many you want. Of course the code is now unreadable...

It's been my dream for a couple years now to try and get all the folks interested in db access to work together to get a Boost library and then subsequently a standards proposal completed.

Well here's my view on the subject, for what it's worth. Few applications will be portable between databases due to the feature differences between those databases. So the benefit of a standard API is minimal: it doesn't make your application portable, but it might make you more productive on your next project when it's on a different platform. IMHO, where Boost can help is by providing the building blocks that can be used to build database-specific (and maybe application-specific) interfaces, as I have done. My PostgreSQL library greatly benefits from the use of libraries including preprocessor, iterator_facade, shared_ptr, lexical_cast, type_traits, string algorithms, etc. In my present experience, the weak spot with C++/SQL interfacing is with the representation of query results. I want it to be a sequence<struct>, and sequence<tuple<...>> just isn't quite good enough because of the awkwardness of accessing a member of a tuple compared to a field in a struct. struct thing { string name; int qty; }; Query<???> get_things(.....); sequence<thing> things = get_things(); This needs either some sort of introspection/relection, or an "IDL compiler" type of approach. Similar to serialisation of course. Now this is something that I would love to see Boost get involved with. I have a vague recollection that Bjarne Stroustrup was involved with an introspection project at one time; I don't know if this came to anything.

I'd love to see a detailed review from you of the SOCI interface -- advantages, disadvantages, etc.

The 'operator,' syntax is not immediately appealing :-( Phil.