I agree - I didn't say anyone should use it ;-)
Personally, I don't have a single use of it in my current working copy
- I just checked. Plenty of resizes, but no reserves. If I need a big
enough collection that it's an issue, I normally end up using a
different kind of container anyway, though not specifically to avoid
this.
I have my own vector ADT based on a multiway tree, though only because
it was convenient given the map, set etc ADTs based on the same
underlying code - they all support log n subscripting. Writing the one
extra wrapper seemed prudent at the time, but I don't think I've ever
used it. If I wanted a huge vector (perhaps a very large audio file) I
might use this since it supports efficient inserts anywhere in the
container - though I'd have to add some bulk ops first.
For video, I wouldn't use it - I'd use a normal vector of pointers,
either to frames or GOPs. An hours video is only in the order of
100,000 frames anyway. And I might just use an vector of pointers to
chunks even for the huge audio file case.
The word "thousands" in my earlier post was out by several orders, I
guess.
I needed a 64 million item 3/4 GB array recently. But it was
fixed-size, so I used a fixed size array, not a vector. If I had used
a vector, I would probably have used reserve.
Strictly I did use a vector with millions of items at one stage -
underlying a priority queue that held up to approx. two million items.
Copy overheads *were* an issue here, but not so much from memory
allocation as from the items flowing through the queue. I solved it by
using a more specialised queuing method, putting items into the
location in the main array where they'd be needed (with some collision
handling).
But even that was for a programming challenge thing that I was just
doing for fun.
http://projecteuler.net/
Problem 211 - it turns out I solved it the hard way, but what the
hell.
Wish I could justify more time for these problems. I've had a plan for
problem 210 (but no code yet) for about a week. This time doing it the
easy way ;-)