|
Boost : |
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-03-15 14:38:59
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk