Why does std::vector initializes its content?

Question

Lets say I want to create a vector and call iota on it:

std::vector<int> v(1000);
std::iota(begin(v),end(v),0);

The vector is actually 0-initialized in the constructor. The problem would be the same with:

std::vector<int> v;
v.resize(1000);

I could use reserve, but then I can't call iota. And I see no elegant way to not zero-initialize (maybe with a custom allocator...?).

Why was vector designed in such a way? I know that Stepanov and collaborators very carefully crafted the STL and there is very few flaws. But to me, it is one in the sense that it seems to conflict with "you don't pay for what you don't use". What was the motivation of such a design?

Is there a consensus that retrospectively, it should not have been done like that? (e.g. as it is the case with the unsigned size_t used for size() where people seem to agree that it should have been the same type as difference_type because we are comparing indices and size() so often).

More information

Performance

Some comparisons regarding the generated code. Does the compiler optimize the 0-init away? It is difficult to look at the assembler when using vector because it does a lot of stuff so I tried this code:

int main() {
    int* v = new int[1000]; // clearer for reading assembly
    fill(v,v+1000,0);
    iota(v,v+1000,0);
    return v[999]; // do not optimize away!
}

Result here. Then with std::fill removed

Simple enought right? Well the assembly is not the same with gcc or clang-O3, and it is longer with std::fill, which generally indicates that instructions are actually issued.

So unless I am misinterpreting, it does matter.

History

The code of the original STL can be found here. In version 2, the content of the vector was already default-initialized. It seems like the commitee validated what was already there.

Comparison to std::array

Some people in the comment believe that you absolutely must initialize the content of the vector. But the proof that this is really a design decision is the fact that std::array, on the contrary, does not default-initialize its memory. So maybe it is easier, or makes more sense, to implement vector and array the way they are, but the other way around would have been possible, for both.

Answer 1

Actually, you can avoid this. To quote from cppreference for, for example, resize:

additional default-inserted elements are appended

And the page discussing C++ named requirements: DefaultInsertable says (emphasis mine):

If value-initialization is undesirable, for example, if the object is of non-class type and zeroing out is not needed, it can be avoided by providing a custom Allocator::construct

Finally, a link back to Stack Overflow (!) shows how this can be done (I have not analysed this code in any detail).

Of course, for non-POD types you do want the new elements to be default constructed. Otherwise, accessing them (or even trying to assign to them) would cause UB.

Answer 2

The various properties of std::vector are designed for specific use cases, and to meet certain requirements. Some of those requirements are:

1. Contiguous memory
2. Constant amortized time complexity for push_back
3. Random access iterators

And perhaps a few others.

There are other containers in the C++ library that have other properties and are optimized for other use cases, like std::list or std::queue. This is why there are different containers: they are optimized for different situations. std::vector requires a copyable/movable type. Other containers do not. If you have a non-copyable/movable type you cannot use std::vector at all.

No claim is made that either std::vector, or any other container, will provide optimal results in every possible situation. There is no jack-of-all-trades container in the C++ library that does everything better than everything else. This is why different containers exist, and a key factor in using them correctly is understanding what each container is good for.

You've described several situations where std::vector is not going to produce optimal results. This does not indicate a flaw in std::vector's design, it is simply not what it's intended to do.

Why was vector designed in such a way?

It was designed in order to provide optimal results in specific use cases.

What was the motivation of such a design?

The motivation for such a design was, primarily so that std::vector provides optimal results for:

1. Contiguous memory
2. Constant amortized time complexity for push_back
3. Random access iterators

Is there a consensus that retrospectively, it should not have been done like that?

No, actually quite the opposite. The current consensus is that std::vector gives surprisingly good results (when used correctly) with modern CPU hardware which excels with contiguous memory access, even when compared when other containers that would, at first glance, provide a better match for certain use cases.

Answer 3

Not really an answer to your question, but rather an answer to your problem (untested code):

vector<int> v;
int val = 0;
v.reserve(1000);
std::generate_n(std::back_inserter(v), 1000, [&val]() { return val++; });