From: Calum Grant (calum_at_[hidden])
Date: 2005-10-03 15:07:01
> > 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 >
> 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> )
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk