Also, many queries have a large number of conditions, so the C++ syntax will get very long and so is *much* harder to read (and write!)
As for avoiding macros, IMHO using macros is fine in this context. Macros are code-generators, and that's exactly what Calum's using them for. Again, there's no reason a declaration of a table in the DSL has to look like a C++ declaration.
Macros are useful tools - you only have to look at Boost.PreProcessor to see how powerful it can be! However, macros/preprocessor sould be, wherever possible, restricted to implementation (like Boost.Function).
As I mentioned above, having a Boost.Spirit-style SQL syntax would complement the direction that C++/Boost is going with respect to describing external constructs (RegExes, BNFL grammars) within C++.
The RML database and results could be kept in tuples, so CREATE TABLE would be:
No - RML results are iterated not stored.
typedef boost::tuple< std::string, std::string, int > people_table; static const int first_name = 0; ...
I think an enum would be more appropriate.
I only have limited knowledge of SQL syntax, but we could then have something like:
rml::sql_statement results = select_( item_<first_name> && item_<last_name> ) .where_ [ item_<age> >= 30 ]
BOOST_FOREACH( data = results( rml_database )) { std::cout << get<first_name>( data ) << std::endl; }
I think the misconception is that results are not stored in a temporary table. The problem with the above is the type of rml::sql_statement. It is very complicated and would be different for each query. Specifically the iterator is generated to be able to evaluate the query whilst making use of indexes, and is a different type each time. You would need auto statement_results = select(people, people.age>=30); which is significantly tidier than the Spiritesque syntax. Calum