Why do STL containers use copy to resize?

Question

Do all STL containers that implement resize use copies to populate new items, even if the copy source is a default-built object?

Why is this done?

I do not see the benefits and some value.

---

As a context, I came across this when looking for a random access container for elements that cannot be copied :

Answer 1

This saves on complexity. We definitely need a copy build script, and the default build can be modeled as a replication of the default built object.

The decrease in performance is negligible. Writing zeros is approximately equal to the speed of copying zeros. The compatibility limit is zero, since all containers require redistribution. The default design, on the other hand, is not required.

If you really want to use standard containers with non-copyable objects, look at C ++ 0x and in-place using emplace . However, there is no method for emplace multiple elements at once. (If you use deque , there should not be a large performance penalty in the emplace loop versus resize .)

Answer 2

In your case, you might be better off storing pointers to those objects in the container - you can copy the pointer.

As for copying in the container; what is the alternative? If you need to reallocate a new block of memory to store what was saved, you need to get the existing data as soon as possible!

Answer 3

The only reason I can think of this behavior is because a copy is required to support pasting and pasting a container. You should be able to create a container that supports resizing in the same way as deque (paged and non-contiguous), which by default creates new elements. However, you will have to prohibit the purpose of the entire container along with the insertion of elements - you can change the objects created in the collection instead.

I assume that no one has seen the need for a collection that does not support insertion and does not implement value type copying. As another note, you probably should mark it as a wiki before it closes;)

Answer 4

Standard containers define CopyConstructible and Assignable requirements for the value type, and these requirements are sufficient to support all operations with containers and sequences (you may also want them to be comparable for associative containers, but even this is not required since you can supply a comparator instead) .

What you are asking for is to have one set of requirements for a set of operations consisting of a part of a container plus something from a sequence (namely the 1-parameter resize() in those containers that never move their contents, operator[] , clear() and the iterator interface, excluding *it = t ), and another set of requirements for the rest. Standard libraries prefer to do this the other way around: select a general set of requirements that cover almost everything, and then have additional requirements for small functionality (for example, the requirement to be the default line by line for calling resize() without specifying the second parameter).

The containers were simply not designed for your specific set of operations - copying and assignment are an integral part of what they are designed to do, which should contain the values ​​that they put into them, so I assume that in Stepanov’s mind this is not “little functionality” " Thus, broader requirements exist because the Container abstraction is larger than the proposed ResizeableCollectionOfDefaultConstructedObjects. In fact, take resize() , and CollectionOfDefaultConstructedObjects is just an array. I assume that the designers of the STL and C ++ standard did not meet your use case often enough to think that it should be disregarded.