Boost logo

Boost :

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 >
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk