Re: [boost] Any interest in... ?

From: Richard Scott (rtscott_at_[hidden])
Date: 2002-04-27 16:30:26

Arkadiy Vertleyb
Dmitriy Arapov

I think this concept might be very useful in self configuring, distributed
system design.  However, can we use template arguments to use container
classes other than those from STL?

If not, it still is a very nice concept.

Richard Scott
----- Original Message -----
From: "Vertleyb" <vertleyb_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Dmitriy Arapov" <dmitriy_arapov_at_[hidden]>
Sent: Saturday, April 27, 2002 12:44 PM
Subject: [boost] Any interest in... ?

> Hi everybody,
>
> We used template meta-programming technics to implement a library that
> defines a type-safe "relational table" container, as well as the full set
of
> relational operations on such containers.
>
> Any type that can be used in an STL container, can be used as a column
type.
> For example, one could define a table like following:
>
> ------------------------------------------
> using namespace rel;
>
> COLUMN(c1, int);
> COLUMN(c2, std::string);
>
> typedef table<tuple<
>     list<c1,
>     list<c2> > > > table_t;
>
> table_t tab;
> tab.insert(tuple_t(1, "line1"));
> tab.insert(tuple_t(2, "line2"));
>
> print(projection<list<c2> >(tab));
> --------------------------------------------
>
> The result will be:
>
> line1
> line2
>
> The rel::tuple class differs from tuples::tuple, and is based on the idea
of
> loki::GenScatterHierarchy suggested by Andrei Alexandrescu (In fact, all
the
> idea of writing the library was inspired by this book).  We didn't used
loki
> though, since we wanted the library compiled by MSVC (because of the same
> reason we use our own implementation of typelist, select, etc.).  The
tuple
> class, therefore, is designed as following:
>
> Each column is represented by a class.  The above COLUMN macro unwrappes
> into something like this:
>
> class c1 : public column<int>
> {
>     ...
> };
>
> As is clear from the example, columns are placed into a typelist, and
passed
> to the tuple class template, who inherits from all of them.  Then
> static_cast is used
> to access individual fields.
>
> We believe using classes as column identifiers is quite benefitial, since
> classes are much easier to operate at compile time than strings.  We found
> no limitations so far.
>
> Each operation is itself a "table", so it's possible to combine them,
> something like this:
>
> print(projection<list<c1> >(cross_product(tab1, tab2)));
>
> The library now compiles with MSVC and G++ (thanks to the idea of
> "identity", "borrowed" from mpl, the number of #ifdefs is minimal), and
> implements the following relational operations:
>
> -selection
> -projection
> -cross product
> -intersection
> -difference
> -union
>
> as well as some additional operations and utilities:
>
> -fast selection and join based on the sort order
> -groupping operations
> -print, serialization, etc.
>
> We beleve there is a range of tasks, where one could benefit from the
> relational algebra without the need to use an external database and ODBC.
> For such applications our library provides the benefits of consistency and
> type safety, ensured by the compiler.
>
> Please let us know if there is any interest in such a library.
>
> Arkadiy Vertleyb
> Dmitriy Arapov
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost