|
Boost : |
From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-11-04 16:50:25
----- Original Message -----
From: "Arkadiy Vertleyb" <vertleyb_at_[hidden]>
> Can't we achieve the same result with:
>
> c1* field_c1 = 0;
> tuple[field_c1] = 5;
>
> ?
>
> Arkadiy
Yes, but I thought you didn't like the NULL pointer?
I also find the null not likeable.
--Joel
PS> In convert.cpp you have
#include "convertion.h" and convertion<...> instantiations.
Wouldn't that be "conversion" instead?
> "Joel de Guzman" <djowel_at_[hidden]> wrote in message
> news:003101c2841b$f916a730$4f4ca7cb_at_kim...
> >
> > ----- Original Message -----
> > From: "James Curran/MVP" <jamescurran_at_[hidden]>
> >
> > > Shouldn't this work?
> > >
> > > template <typename fld>
> > > fld& Field(Tuple& tuple)
> > > {
> > > return tuple.field((fld*)0);
> > > }
> > >
> > > Field<c1>(tuple) = 5;
> >
> > or how about:
> >
> > tuple[field<c1>()] = 5;
> >
> > where field:
> >
> > template <ColumnT>
> > struct field { /*...*/ };
> >
> > The user, may even declare:
> >
> > field<c1> const field_c1 = field<c1>();
> >
> > Then:
> >
> > tuple[field_c1] = 5;
> >
> > --Joel
> >
> >
> > > 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
> > > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> > >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk