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

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-04 13:39:12

You probably meant to pass two template parameters, fld and Tuple?

The problem is that, once you start using non-member functions, the compiler
can't properly handle const/non-const tuples.  This code would not work for
a const tuple, so one more overload (taking const Tuple&) has to be
provided.  And once we do this, we'll have the ambiguity problem for const
objects :o(

I would assume, that if you can overload a function based on the constness
of the object, you should be able to do the same based on the constness of a
parameter, but aparently this is not the case...

Of course, an option would be to use 2 different functions: get_field() and
set_field().  Then your approach should work.

Arkadiy

"James Curran/MVP" <jamescurran_at_[hidden]> wrote in message
news:aq62gm$afp$1_at_main.gmane.org...
> Shouldn't this work?
>
> template <typename fld>
> fld& Field(Tuple& tuple)
> {
>      return tuple.field((fld*)0);
> }
>
>  Field<c1>(tuple) = 5;
>
>
>
> --
> 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
>