On Thu, 23 Jan 2003, David Abrahams wrote:
> Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
>
> > On Thu, 23 Jan 2003, David Abrahams wrote:
> >> No, I mean the complexity-of-expression issue.
> >
> > Hmmm, I don't see how that issue applies.
>
> I don't know what you mean by that. Are you saying that Andrei was
> making an invalid argument? I wouldn't agree with that.
Andrei's argument was that this form for a for_each loop:
inline void do_my_function(string&, void_) {}
template <class Lst>
inline void do_my_function(string& s, Lst lst)
{
my_function<front<Lst>::type>(s);
do_my_function(s, pop_front<Lst>::type());
}
...
do_my_function(s, my_list());
, which he posted here:
http://lists.boost.org/MailArchives/boost/msg42374.php
is less complex than the solution you posted, which uses MPL's for_each:
http://lists.boost.org/MailArchives/boost/msg42369.php
Somewhere in reading the thread I replaced the rather simple definitions
of "func" in your message with an MPL metafunction class. Re-reading it
now, I see that the solution I'm proposing would require almost identical
code to what you posted, with the exception that:
mpl::for_each<my_list>(func(s));
... would become:
for_each(my_list().begin(), my_list().end(), func(s));
Anyway, Andrei's argument is a good one, and I see that it holds against
the for_each that I'm proposing as well.
> > STL users know how to write function objects. It's not a gigantic
> > leap to write function objects with a templated function call
> > operator (at least, it isn't if you've already decided to play with
> > template metaprogramming). The rest of the syntax is inherited from
> > STL. I don't see any extra complexity here. Granted, it means
> > pulling in a lot more code than Andrei's version,
>
> And writing a lot more code.
Yes, those wretched function object->overloaded function bridges take up a
lot of space, even if they are trivial.
Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
