Recently my friends and I are thinking about the std::vector class.
We feel that its object moving algorithm is not optimized.
when it comes to re-size the buffer, Here are the things it will do:
1. allocate a big enough buffer (no problem)
2. copy some of the old objects into the new buffer. (problem starts
3. insert new value into the new buffer
4. copy the rest of the old objects into the new buffer.
5. destroy the old objects by calling dtor.
6. deallocate the old buffer. (no problem).
The problem we noted is that the copy+dtor is sometimes expensive and
Suppose I have a string class, which internally holds a pointer to a
When asked to copy, I'll need to allocate new storage, copy the entire
But if I know it's just a move, I can simply copy the pointer of the
buffer. WAY faster!
Also, we believe that for many types, a memcpy would be sufficient for
the object move purpose.
Now, the question is: why doesn't stl delegate the object move to the
allocator object so that the programmer can customize the allocator
accordingly to achieve the optimal performance? It sounds like an
obvious thing to do.
I actually revised std::vector with the extended allocator concept.
and it worked. It does not require any language change or hacking, all
it does is to delegate the move to the extended allocator and let the
programmer do the optimal "move" instead of doing it all by itself.
Whether "memcpy" or any other user-defined move is all up to the
I'm sure many people would have been wondering about the same thing,
but what puzzled me is that it seems possible to make vector both
generic and optimizable. Why vector is not doing this though?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]