In C++, I'm more likely to write a struct/class which implements operator() than an actual function. It lets me write code like this, which does mutate state, but I put it off as long as possible:<p><pre><code>  xformerlist&#38; lbrace = node.children.front().xformations;
  xformerlist&#38; rbrace = node.children.back().xformations;
  fn_and&#60;shared_variable&#62; row_and_flat(&#38;shared_variable::is_row, &#38;shared_variable::is_flat);
  const sharedset&#38; flat_ins = filter(row_and_flat, set_union_all(in, inout));
  const sharedset&#38; flat_outs = filter(row_and_flat, set_union_all(out, inout));
  const sharedset&#38; flat_all = set_union_all(flat_ins, flat_outs);
  make_conditions&#60;gen_in&#60;row_access&#62; &#62; make_gen_in_row(parcond, conds, local_depths);
  make_conditions&#60;gen_out&#60;row_access&#62; &#62; make_gen_out_row(parcond, conds, local_depths);

  append(lbrace, fmap(make_gen_in_row, flat_ins));
  append(rbrace, fmap(make_gen_out_row, flat_outs));
</code></pre>
I imagine that code would give a lot of people fits. In my current project, I ran with a more functional approach to C++. I don't know if I'll keep everything I've used in this programming style, but I certainly will keep some of it.