Hi,
"Joel de Guzman" <[EMAIL PROTECTED]> wrote in message
news:005301c286b5$15290e90$5f4ca7cb@;kim...
> Nice! Now, there's one more macro to remove :-)
Done. I just uploaded the corrected version. We added a new class,
column_name, which is just a light-weight proxy to the columns we have.
After these changes, one can define a column like this:
// regular
class c1 : public column_name<column<c1, int> > {};
// calculated
class Fn {
template<class Tuple> int operator()(const Tuple& tuple) {
...
}
};
class c2 : public column_name<calculated_column<c2, int, Fn> {};
We think, disregard unfortunate name repitition used to ensure uniqueness,
this says what it should say:
c1 is a column name for a regular column with an integer value;
c2 is a column name for a calculated column with functor Fn that returns an
integer;
Macros COLUMN and CALCULATED_COLUMN can be used as they were used before,
but they are no longer nesessary. This is a positive side effect -- I
didn't expect these macros to become unnesessary (in fact I was SURE we'll
not be able to get rid of them :-)). The reason it happend -- we now derive
the tuple from column or calculated_column directly, rather than through c1
and c2. So we don't need to define constructors on c1 & c2, which was the
primary reason for having this macros.
Fields can be accessed like this:
tuple[c1()] = 5;
int n = tuple[c2()];
Note that passed objects are light-weight, so we don't pay much penalty for
their construction even if the optimization isn't done.
Again, the FIELD macro can be used as before, but it's not necessary. We
will most likely remove it in the future.
Looking forward for more feedback.
Arkadiy
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
