Comments on: Getting more out of the range-based for statement in C++11 Sat, 06 Jul 2013 19:02:18 +0000 hourly 1 By: Christian Christian Sat, 06 Jul 2013 19:02:18 +0000 The main reason for the split in enumerate() was that the code

for (auto e : enumerate(container)) e.value = 12;

looked surprising. Does that change the container or not?

First I made value const so this would just not compile. But in practice, you often do want to change the value. Once I decided to change the name to enumerate_byref I felt I also had to provide enumerate_byval.

Currently I’m leaning towards just not having enumerate – the code may be more verbose, but it’s also more readable.

By: Leo Goodstadt Leo Goodstadt Fri, 14 Jun 2013 18:07:57 +0000 Nice code. Could you explain a little more the rationale for splitting up enumerate_byref and enumerate_byval.

More to the point, enumerate_byval seems to provide little benefit over enumerate_byref. Benchmarking seems to suggest that this is almost no overhead in passing by reference instead of by value, e.g. for integers.

The only other point is if the user is going to modify the value / counter inside the loop, and he/she wants to discard such changes. This seems to be an odd and confusing paradigm…

Admittedly, the usual distinctions between using const T&, T& and T “don’t work” when using an enumerating range. But that is true for enumerate_byref as well.

Thus with:

for (auto e : enumerate_byref(container))

even with the “byref” in the name, are we going to know for sure that “e.value” here is a reference, rather than a copy?

Have I missed anything?

By: Leonid Volnitsky Leonid Volnitsky Sun, 24 Mar 2013 11:34:13 +0000 There is somewhat similar project at