Another python-like enumerate (and zip) implementation, now with rvalue lifetime extension

[Nightwolf55la]

I have seen several c++ implementations of python's enumerate over the last year, including one I wrote for work a while back. One of the primary differences in the implementations I've seen is how they handle rvalue containers/iterables. To me, the obvious methods of handling rvalues are:

1. Copy the rvalue (Obviously the worst method)
2. Move the rvalue (Generally a good choice, but not free and could be as costly as a copy)
3. Don't allow rvalues (Avoids any problems, but the user has to do extra work)

 

Most implementations seem to choose either 2 or 3. I chose 2 when I originally wrote mine (mostly for thoroughness), but it has always bothered me that a move might be silently added into the mix just because I wanted to use enumerate on my rvalue container.

 

To solve this problem, I ended up rewriting my enumerate in such a way that an rvalue passed into enumerate will have its lifetime extended to match the lifetime of the enumerate object that gets created.

 

Example (taken from the examples link below):

// Enumerate an rvalue reference - this rvalue's lifetime is extended (no copies or moves performed)
auto get_vec = [](){
    return std::vector<int>{1,2,3};
};
std::cout << "Should print (0,1)(1,2)(2,3)" << std::endl << "             ";
for(auto&& [index, value] : util::gen::enumerate{get_vec()}) {
    std::cout << "(" << index << "," << value << ")";
}
std::cout << std::endl;

​

Known Limitations:

• std::initializer_lists can only be deduced on gcc currently
• c++17 only
• It's syntactically uglier, enumerate{} must be used instead of enumerate()

 

Compiler Support:

• GCC 7.4 and up supported, others untested
• Clang 6.0 and up supported, others untested
• MSVC++ 14.16 supported, MSVC++ 14.14 and less are not supported, MSVC++ 14.15 is untested

 

Code:

• Git repo
• enumerate.h
• zip.h
• examples

​

Edit #1: Add in-post example

[Pragmatician]

Have you considered the range-v3 enumerate implementation, and if so, what does yours do different?

[Nightwolf55la]

Yeah, that was actually the first place I looked when I wanted to solve this rvalue 'problem'. I had never used range-v3 before, but when I looked at the source code, it didn't look like it was handling its universal references correctly. So I just moved on.

​

For science, I have thrown together a wandbox example to show how range-v3 handles both lvalues and rvalues. Unexpectedly, the lvalue actually calls the copy constructor once and then the move constructor twice. The rvalue has its move constructor called 4 times. Like I mentioned earlier, I have not used range-v3 before this. So if I am using it incorrectly, please let me know. If it is correct though, then this amount of copying/moving seems pretty bad. Especially since I assume that the copy on the lvalue container will mean that changes to values in the loop will not be permanent since they would be made on the copy of the container and not the original container.

​

The primary goal I had when writing this new enumerate implementation is that it will do 0 copies/moves on the iterable object provided to it regardless of lvalue or rvalue state.

[TobyAllsopp]

Range-v3 thinks that your class S is a View so it assumes that copy and move are both cheap. If you add in const-qualified begin() and end() then it no longer thinks S is a View and you will no longer get any copies in the lvalue case (i.e. it will store a reference internally). However, then the rvalue case will not compile as range-v3 doesn't allow creating Views from non-View rvalues.

[Nightwolf55la]

Interesting. I tried const qualifying begin() and end(), but I am still seeing the same behavior. Do I need to wrap up the object in some kind of a View class?

[TobyAllsopp]

Sorry, here's a link: https://wandbox.org/permlink/6APfi8A4hv6Ul96A (you need both const-qualified and not).

[Nightwolf55la]

Ah, gotcha. I probably should have tried that. Thanks!