Boost :

jamescurran_at_[hidden]

--
Truth,
James Curran
www.NovelTheory.com  (Personal)
www.NJTheater.com   (Professional)
www.aurora-inc.com   (Day job)
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
news:apv09f$1eq$1_at_main.gmane.org...
> 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
> >
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>