[boost] Re: Re: relational table as an STL container -- anyinterest?

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-01 18:00:53

I like this "when" that you use instead of "if" :o))

We have two basic macros: COLUMN and FIELD.

I don't think COLUMN can be eleminated.  What it does -- it defines a class
a1 that holds an integer value.  This class is derived from rel::column<int>
(we can't use rel::column<int> directly, because then there would be nothing
that distinguish one int colomn from another).  The reason we need macro --
we need to define a constructor from int, that just forwards to
rel::column<int> constructor...

The FIELD macro is used to access a field inside a tuple.  It unwraps into
the call to the templated method on the tuple class that further calls
static_cast to access the field.  So we now have:

FIELD(tuple, c1) = 5; // we have it now

but would like to have:

tuple.field<c1>() = 5; // we want it like this

Neither MSVC nor g++ allows us to do this.  Is there anything about the
standard that makes it illigal?  The best we could do is:

tuple.field((c1*)0) = 5; // pretty ugly, isn't it?

So, we decided to have the macro :o((

One way to deal with this is to use COLUMN macro to reduce the need in the
FIELD macro.  In addition to the above mentioned constructor, it could
define, say, getter and setter, so we could do the following:

tuple.set_c1(5); // better.
// tuple.c1() = 5 would be even better, but this name is reserved for the
constructor

Unfortunately not all the columns are defined by the COLUMN macro.  Some,
like renamed fields, are generated automatically, and can't use the latter
approach.

Any suggestions about this (or anything else) are most welcome.

Arkadiy

"Joel de Guzman" <djowel_at_[hidden]> wrote in message
news:00b701c281eb$bcc15640$0100a8c0_at_kim...
> Just a quick question: Can you eliminate the ugly MACRO?
> When the library ever gets into boost, that would have to be
> renamed to something like:
>
>     BOOST_LIBRARY_NAME_COLUMN(a1, int)
>
> Yuck!
>
> --Joel
>
> ----- Original Message -----
> From: "Arkadiy Vertleyb" <vertleyb_at_[hidden]>
>
> > 1. We can have a column whose type is a table (see code below);
> > 2. As far as other relations (operators) are concerned, right now we
can't
> > do this because currently the operators are not default constructible.
This
> > could be easily fixed.
> > 3. Just out of curiosity, how would you use this feature?  It might
become a
> > major advantage of this library over traditional RDBMSs.
> >
> > Arkadiy
> >
> > ==============================
> >
> > COLUMN(a1, int);
> > typedef tuple<list<a1> > tuplea_type;
> > typedef table<tuplea_type> tablea_type;
> >
> > COLUMN(b1, int);
> > COLUMN(b2, tablea_type);
> > typedef tuple<list<b1, list<b2> > > tupleb_type;
> > typedef table<tupleb_type, list<b1> > tableb_type;
> >
> > void foo() {
> >   tableb_type tab;
> >   for (int i = 0; i < 5; ++i) {
> >     tablea_type t;
> >     t.insert(i);
> >     t.insert(i * i);
> >     t.insert(i * i * i);
> >     tab.insert(tupleb_type(i, t));
> >   }
> >   for (tableb_type::const_iterator it = tab.begin(); it != tab.end();
++it){
> >     cout << "tuple " << FIELD(*it, b1) << endl;
> >     print(FIELD(*it, b2));
> >   }
> > }
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>