Re: [boost] MPL algorithms vs. type lists

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-26 15:01:33

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 26, 2002 12:46 PM
Subject: Re: [boost] MPL algorithms vs. type lists

>
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > Because the arguments are the same. The reasons for using mpl::for_each
> or
> > mpl::accumulate are the same as the reasons for using std::for_each or
> > std::accumulate. You're citing one pitfall of using MPL -- more lines of
> code
> > -- and I'm trying to show that the same pitfall occurs in STL, but the
> C++
> > community still agrees that the use of STL algorithm invocations is
> preferred
> > to hand-coded loops.
>
> I don't think there's universal agreement on that point, at least, not
> until you introduce something like Boost.Lambda. However, MPL has lambda
> expressions. IMO that can make a huge difference.
>
Indeed.
I think that the MPL approach could start to result in less and more
readable code as lambda-style support is added and supported but compilers.
For example, I write a lot more hand-coded loops than calls to std
algorithms. Most of the times, the body of the loops are just too simple to
justify the extra complexity of introducing a function object. So initially,
I could tend to agree with Andrei as I would have similar arguments for some
STL based code which I could write quite easily.
However, with lambda facilities this is starting to change.

I think that a similar shift will eventually occur with mpl. Today, writing
mpl code might involve more lines of code if you haven't yet explored and
understood its lambda facilities, or if the compiler you are targeting
doesn't support that. But as Doug have shown very clearly, MPL code can be
improved a lot with a clever usage of its lambda sublibrary.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com