Why write it yourself if you can use **Boost.Range**‘s `irange`

. You can even adapt this to set the starting index to `0`

and get `std::iota`

type behavior (called `iota_n`

here).

```
#include <boost/range/irange.hpp>
#include <iostream>
template<class Integer>
decltype(auto) iota_n(Integer last)
{
return boost::irange(0, last);
}
template<class Integer, class StepSize>
decltype(auto) iota_n(Integer last, StepSize step_size)
{
return boost::irange(0, last, step_size);
}
int main()
{
for (auto x : iota_n(5)) // 01234
std::cout << x;
}
```

**Live Example**, using Clang 3.4 return-type-deduction in C++1y mode (also supported by gcc 4.9, and other compilers soon (use trailing `-> decltype(/*statement inside function*/)`

return types for C++11 compilers)

You can make the class template with trivial changes (add `template<typename T>`

and change `int`

by `T`

in your classes), then make a construction function that deduces integer types:

```
template<typename T>
LoopRange<T> range(T from, T to)
{
static_assert(std::is_integral<T>::value,
"range only accepts integral values");
return { from, to };
}
```

That will even allow you to explicitly tell what kind of integer you want to loop with if needed:

```
for (auto i: range<unsigned>(0, 5))
{
std::cout << i << " ";
}
```

If you need to generate indices to iterate through a `std::vector`

, this can be useful since `std::vector<T>::size_type`

is probably bigger than `int`

. While the `static_assert`

avoids some potential problems with floating point values, it also inhibits the use of integer-like classes (for example, a hypothetical `BigNum`

class).

You can simplify some of your functions thanks to list initialization. For example, used in a `return`

statement, it sallows you not to explicitly repeat the return type (unless the return type’s constructor is `explicit`

):

```
LoopRangeIterator begin() const
{
return { from };
}
LoopRangeIterator end() const
{
return { to };
}
```

On a side note, such a `range`

utility would also be interesting if it worked with floating point numbers, and maybe decimal numbers in the future (akin to Python’s `numpy.arange`

). However, you would have to special-case the class for those types if you want to avoid problems: if you repeatedly add the same floating point (say `0.01`

), you will accumulate rounding errors. Computing every value from the base value with a multiplication could be away to circumvent such a problem.

If you have `operator!=`

, you should also have `operator==`

for symmetry:

```
bool operator==(LoopRangeIterator const& other) const
{
return value == other.value;
}
```

In addition, it’s more common to overload `operator!=`

in terms of `==`

:

```
bool operator!=(LoopRangeIterator const& other) const
{
return !(value == other.value);
}
```