Hi,

thanks, this is a good idea. However, the proposed change only adds the size member to the default range_proxy without a step size. It should also be added to the range_proxy::step_range_proxy to keep the interfaces consistent.

I can add the member size()for the class range_proxy::step_range_proxywith the following formula:

return static_cast<size_t>(std::floor((*end_ - *begin_) / step_));

Unfortunately this yields wrong results (the correct result in all cases is 4):

• range(1, 8).step(2).size() = 3
• range(8.0, 1.0).step(-2.0).size() = 18446744073709551615
• range(8, 1).step(-2).size() = 0

From my understanding the result should be 3 because the range is [1,8[. The number 8 cannot be reached because it is associated with the end() iterator. (I should have think harder before writing this sentence...)

The code below is an update for the method range_proxy::step_range_proxy and take into account all possible cases (increasing/decreasing/empty range with positive/negative/null step).

// null step
if (step_ == T(0)) {
    return static_cast<size_t>(-1);
}
// increasing and null range
if (*end_ >= *begin_) {
    if (step_ < T(0)) {
        return 0;
    }
    return static_cast<size_t>(std::ceil(double(*end_ - *begin_) / double(step_));
}
// decreasing range
if (*end_ < *begin_) {
    if (step_ > T(0)) {
        return 0;
    }
    return static_cast<size_t>(std::ceil(double(*begin_ - *end_) / double(step_));
}

I did not test this code in C++, but from tests in another language it will give your the result 4 in your examples. The code range(0.1, 0.11).step(2).size() returns 1.

Finally, the formula used in the range_proxy::size() method should be updated to take into account the case where the range is not valid (i.e. *end_ < *begin):

if (*end_ < *begin_) {
    return 0;
}
return static_cast<size_t>(*end_ - *begin_);

From my understanding the result should be 3 because the range is [1,8[. The number 8 cannot be reached because it is associated with the end() iterator.

Right, 8 cannot be reached; so the output is 1, 3, 5, 7, which is four different numbers. And analogously for the other ranges.

You are right... I updated the code in my previous comment to compute the good size.

Looks good. Except the step_ == 0 case, that’s not meaningful and should probably be caught at instantiation.

Anyway, if you write a commit I’ll merge it!

@klmr I finally implemented the range_proxy::step_range_proxy::size() now available in this PR. I updated the code as we discussed and I tested it in the file test.cpp.

Wow, what a coincidence: almost exactly a year after your last change. Apologies for the delay!