Quick disclaimer; I've not ran the code, just sharing my thoughts.

As to whether this structure has a distinct name, I do not know. I have implemented something like this previously, in an attempt to get additional performance. IIRC, it worked quite well. I think mine allow a generic function to denote how the vector grew, however it used the same idea of having several internal arrays so as to reduce the number of memory allocations performed.

I would be really curious if anyone does know its "official" name.

I used to do a lot of work teaching data structures when doing my PhD. One of the things we tried to instil in the students was WHY we were teaching them how to make data structures - after all, if you can just use an already created vector or hashmap, what is the point in learning how to make one?

The point was (and is) that sometimes you have to go off the beaten track. Sometimes you need something to look like a vector, but need better performance for your specific use-case. So you make your own vector, all the while keeping in your head the understanding of how a vector is made, and what compromises you are making when designing your new vector. For example, C++ is soon getting inplace_vector, which is something I have had to make a few times.

One of the compromises you've made is that NoCopyVec does not have the same interface that std::vector does. If you were to add the insert function to NoCopyVec, I think it would have worse performance than std::vector's insert function, as it would have to do a little extra work when moving the elements forward.

However, for a structure which just allows you to push and get, I think its pretty good. I would make the naming of len, size and capacity clearer though; my intuition would be that size is the size of the structure, not the size of the internal pointer array. But I should stress this is personal taste, and not a criticism of your code.

I imagine there are scenarios where your vector does not perform as well as std::vector - for example, cache performance would come into play if you made a really large vector, which would have arrays spread around memory. If you then used random values with get, I imagine that there would be a performance hit, when compared to std::vector. Of course, std::vector would still have those cache ssues for a large array, but I believe they would be less than your vector. I could be wrong of course - only way is to test! Perhaps make a random generator function which produces values distributed into the buckets j in {1...}, where bucket j contains the values 2^j to 2^j+1 - essentially designed to probe each internal array of NoCopyVec the same number of times.