My colleague and I discussed whether it is actually faster to pre-declare and recycle as many function variables as possible.

Many compilers won't care as they will internally transform your code in to SSA form anyway, making the debate somewhat moot. Such compilers include Intel's, GCC and LLVM, if the results of 2 minutes of Googling are to be believed.

Yes, we absolutely should. It may be a lambda, but it should certainly be a function object.

Why? Because this allows you to use std algorithms (as well as algorithms from boost, TBB, PPL, and your own template algorithms). This is worthwhile purely for clarity - the function name tells you the number of iterations on the first line of the loop. For/while etc do not do this - you have to examine the body of the loop.

As long as you've got Boost, shouldn't you be using Boost Foreach? In my opinion, it's a lot clearer and easier to use then creating lambdas all the time, and that's assuming that your compiler even supports them in the first place.

As long as you've got Boost, shouldn't you be using Boost Foreach? In my opinion, it's a lot clearer and easier to use then creating lambdas all the time, and that's assuming that your compiler even supports them in the first place.

Boost Foreach is great for std containers, but I've had trouble getting it to work with my own containers/ranges, like the xrange knockoff I mentioned. I'm also a little suspicious of it being a macro - I'm not sure its as type-safe as I'd like. For instance, it seems to have no awareness of const iterators, and insists on providing non-const access. That's a bit of a nitpick admittedly, and it may just be my incomplete understanding of boost's range and iterator concepts.

FWIW I find lambda syntax makes very little difference to me when reading code - I can usually ignore the "[](...)" stuff at the end of the first line. If I'm making a change to the body where I actually care about the capture and parameter passing semantics I can always check it out.