From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-05 23:14:09
"Joel de Guzman" <djowel_at_[hidden]> wrote in message
news:005201c28519$a93589d0$424ca7cb_at_kim...
>
> ----- Original Message -----
> From: "Arkadiy Vertleyb" <vertleyb_at_[hidden]>
>
>
> > Your approach uses different, but related, classes for tuple to derive
from
> > (c1) and for the field access (field<c1>).
> >
> > On the other hand, I once suggested (to be more accurate this is not
exactly
> > my idea -- I borrowed it from somewhere) to pass c1& instead of c1*, so
that
> > the call looks like:
> >
> > tuple[c1()] = 5;
> > employee[last_name()] = "Smith";
> >
> > The above looks pretty nice, except now we should pay the penalty for
the
> > creation of the temporary object. It's not clear whether compilers
would
> > optimize this away.
>
> Oh I'm pretty sure the compiler will optimize away the temporary.
> However, if you want to be sure, there's only one way to find out :-)
You mean by examining the code generated by all current (and future)
compilers? :-)
> > I think we could combine the above two approaches to achieve the desired
> > result. If we get the data from the "column" class into the nested
class,
> > say field, we should get what we need:
> >
> > template <class Type> struct column {
> > typedef Type type;
> > class field {
> > type value_;
> > };
> > };
> >
> > Then tuple<list<c1> > is derived from c1::field, and when tuple[c1()] is
> > called, it's static_casted to c1::field too. The syntax is pretty nice,
and
> > the penalty for the creation of c1 are minimal.
>
> Nice! Now, there's one more macro to remove :-)
And that's all we need to do to be accepted ? :-))))))))
Thanks a lot for your interest in the library. Did you have a chance to
download and try it? We are looking forward to getting any feedback.
Arkadiy