Re: [boost] Re: MPL usage for code generation

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-01-23 13:52:59

On Thu, 23 Jan 2003, David Abrahams wrote:

> Douglas Paul Gregor <gregod_at_[hidden]> 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