[boost] MPL algorithms vs. type lists

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-06-26 09:09:04

On Tuesday 25 June 2002 10:48 pm, Andrei Alexandrescu wrote:
> STL does reduce the amount of code you write quite drastically, and it
> would be hard to convince me otherwise because I know that from direct and
> extensive experience.

I'm not referring to STL as a whole, but specifically to the replacement of 
hand-coded 'for' loops with STL algorithm invocations. I've found that often 
the use of an STL algorithm ends up in more lines of code because one often 
needs to create a separate function object to pass to the algorithm, whereas 
it would otherwise be written inline. Here's a simplified case that I ran 
across a few days ago:

// -----------Hand-coded everything-------------
for (LocationIterator loc = locations.begin(); loc != locations.end(); ++loc)
{
  ValueIterator val = loc->begin();
  Value init = *val++;
  for(; val != loc->end(); ++val)
    init = merge(init, *val);
  loc->merged = init;
}

// ----------STLize inner accumulation---------
for (LocationIterator loc = locations.begin(); loc != locations.end(); ++loc)
{
  ValueIterator val = loc->begin();
  Value init = *val++;
  loc->merged = accumulate(val, loc->end(), init, &merge);
}

// --------------STLize outer loop-------------
struct Merge {
  typedef void result_type;
  void operator()(Location& loc) const
  {
    ValueIterator val = loc.begin();
    Value init = *val++;
    loc.merged = accumulate(val, loc.end(), init, &merge);
  }
};

for_each(locations.begin(), locations.end(), Merge());

In this particular example, there was a 2-line savings when we STLize the 
inner accumulation, but if we then STLize the outer loop we need to create 
another function object to perform the operations in the loop body (Lambda 
library could probably avoid this, but the result expression would be quite 
ugly). The result is that the fully STLized version is 10 lines: 2 more lines 
than the original version, and 4 more lines than the hybrid with only the 
inner loop STLized.

This result is not atypical when writing a nested loop, and I've come across 
it quite a few times. Anything but a trivial nested loop tends to require the 
introduction of a new function object. Not that I'm complaining -- I find the 
last version most preferable (indeed, that's a slightly simplified version of 
what I wrote a few days ago), because it separates the complexity nicely: the 
for_each line obviously says 'we're merging values at each location'. Want to 
know how the merge works? Look up the Merge function object to see how 
merging is done. 

> But why compare mpl with stl instead of concretely
> discussing on mpl as it stands.

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. 

> Because to me it looks like variant.hpp, as
> a sample usage of mpl, is not quite a compelling argument in mpl's favor.
> I'm not sure, but it might be the case that variant's code would benefit in
> terms of length, simplicity, understandability, and compilation times, if
> it would be written without mpl.
>
>
> Andrei

We'll see. Using MPL's placeholders there are a few areas where the variant 
code size could be reduced (for instance, there should be no need for 
details::add_const or details::max_size)

        Doug