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:
xformerlist& lbrace = node.children.front().xformations;
xformerlist& rbrace = node.children.back().xformations;
fn_and<shared_variable> row_and_flat(&shared_variable::is_row, &shared_variable::is_flat);
const sharedset& flat_ins = filter(row_and_flat, set_union_all(in, inout));
const sharedset& flat_outs = filter(row_and_flat, set_union_all(out, inout));
const sharedset& flat_all = set_union_all(flat_ins, flat_outs);
make_conditions<gen_in<row_access> > make_gen_in_row(parcond, conds, local_depths);
make_conditions<gen_out<row_access> > 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));
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.