Hi,
Cool! I can't wait to try the library out for a test drive.
> class c2 : public column_name<calculated_column<c2, int, Fn> {};
I think public isn't needed.
> 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.
Oh, I'm sure it will be optimized!
Regards,
--Joel
----- Original Message -----
From: "Arkadiy Vertleyb" <[EMAIL PROTECTED]>
> 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
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
