OoCcи будет их все больше и больше по мере роста вектора.
Как правильно ответил a guest происходит реаллокация вектора.
использование reserve избавит от "лишних" обьектов

Или можно сделать noexcept move-конструктор. Именно такой будет вызываться при реаллокации вектора, если существует, взамен конструктору копирования.

OoCcНет. Это нехорошо. В большинстве случаев замена конструктора копирования на конструктор перемещения большой выгоды не даёт . Реаллокэйшн нужно исключать. Иначе этот контэйнер работает в а-ля-джава режиме.

Лолшлто? Про замену одного конструктора другим никто не говорил.
Именно move-семантика позволяет избежать копирования при вынужденном реаллокейшне. Разумеется, когда ты знаешь приблизительное или точное количество элементов нужно использовать reserve. Но, вектор так спроектирован чтобы расширяться, вынуждено перемещая объекты в новую область памяти, когда упирается в размер выделенного блока. Так что, когда есть возможность организовать move-конструктор и оператор присваивания для элементов в векторе -- лучше всего воспользоваться этой возможностью.

Dima TМожно поподробнее. Не силен в современном С++.
В С++ нет реаллокейшена, т.е. realloc() не используется.

Реаллокейшн не значил вызов realloc'а. Это просто удобный термин обозначающий определённую последовательность действий в реализации std::vector'а. Например, в док референсе употребляется термин "Reallocation". Не суть, в общем.
Dima TУвеличение размера вектора это как минимум memcpy(), если при этом пресечь вызовы деструкторов и конструкторов, то можно на этом время сэкономить.
memcpy смотря для чего. Для POD-типов memcpy -- вполне себе решение.
А вот для комплексных типов классов и структур не всё так просто. Хотя бы потому что у объекта в векторе тогда вообще не будет возможности хоть как-то уведомить внешний мир, что он-то оказывается переехал по новому адресу. Ну или хотя бы потому что внутри объекта могут быть сохранены указатели на внутренние поля (why not?), что сделает их невалидными после копирования в новое место. Вообще, ЕМНИП нет никаких гарантий, что memcpy'ed объект будет работать валидно, ибо это Implementation Defined. Поэтому по классике старых плюсов, вызываются copy-ctor'ы на только что выделенном куске памяти через placement new и затем деструкторы. Понятно, что по задумке конструктор копирования создаёт копию объекта, в то время как move-ctor просто меняет владение внутренними ресурсами объекта. Советую глянуть это короткое видео от Джейсона Тёрнера, который на наглядном примере объясняет как это работает.

OoCcА move семантика это что за зверь?

RTFM

OoCcЭто и есть замена конструкторов копирования на конструкторы перемещения при реаллокации вектора. Дальше читаем снова моё предыдущее сообщение.
Да нету никакой замены. Конструкторы копирования и перемещения могут сосуществовать в одном классе легко. Вектор при реаллокации смотрит через type_traits есть ли у T noexcept move-конструктор и использует его. Если его нет, он будет использовать copy-конструктор. Если и его нет, попытается найти обычный move-констуктор. Если его нет, то ничего не скомпилируется. Читаем сначала раздел Exceptions/(since C++11) . Дальше подкрепляем матчасть видео из моего предыдущего сообщения.