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) . Дальше подкрепляем матчасть видео из моего предыдущего сообщения.

OoCcГлупости.

В каком месте?

OoCcв 99% случаях замена вектора на декъю решает все проблемы с внутренними перемещениями и лишними обьектами.
Да, дек лишён некоторых недостатков вектора -- вставки в начало и в конец не инвалидируют итераторы, так же как и удаление, так как в памяти он хранится в виде двумерного массива, а не полностью непрерывно, как вектор. Однако тут сразу встаёт вопрос со вставкой элемента в середину, а также вопрос кэширования данных дека CPU. Так что, ни то, ни другое -- не панацея, везде надо искать компромиссы для своего конкретного случая. И в случае с вектором из ваших классов можно значительно уменьшить накладные расходы на реаллокацию реализовав правильно move-конструктор.

CEMbПри релокации вектора (при исчерпании зарезервированного места) вызываются конструкторы? Не верю. Для "пользователя" это вообще невидимое событие, чисто технически необходимое, перенос куска памяти (набора указателей в случае вектора) в новое место.
Ну приехали... Может, стоило хотя бы проверить?

Просто запусти этот код и проверь (обещаю, он не майнит биткойны):



У меня получился такой вывод:

Попробуй объяснить каждую строчку вывода.
Имеем три вызова дефолтного конструктора и три вызова конструктора копирования.

А потом, если ты просто добавишь noexcept к move-конструктору, то будет вызываться именно он:

CEMbединственное, прошу разъяснить, как noexcept влияет на выбор конструктора. У меня (С++11) без noexept вызывался move-конструктор.
ЕМНИП, не noexcept move-конструктор будет вызываться только тогда, когда нет вообще доступного конструктора копирования и есть явно заданый move-конструктор без noexcept'а.
То есть, приоритет выбора такой, сверху вниз:
1. noexcept move-ctor
2. copy-ctor
3. move-ctor
4. error

CEMbтам потому что в векторе хранятся объекты.
Логично. Для POD-типов, включая сырые указатели, ты не переопределишь move-конструктор. В таких случаях, вектор просто делает memmove, что как бы намекает ;-)

CEMbNekZЛогично.Логично то, что один раз закинув объект в вектор, я не должен ожидать повторный вызов конструктора для него, так как сам я объект не перемещаю, да и при растяжении вектора объект перемещаться не должен в идеале.
Может, тогда тебе нужен другой контейнер, например, std::list?

CEMbда не, я просто в векторах указатели/POD храню, так что всё ок.

Тогда ты всё равно должен помнить, что если хранишь умные указатели в векторе, у них, скорее всего, иногда вызывается move-ctor ;-)

CEMbalex_kну а сами объекты размещаются на куче черти где, и последовательный перебор будет со скоростью работы памяти(раза в 3-4 медленнее, чем могло бы)?надо проверить. По идее, не сильно медленнее должно быть, что стек, что куча? В случае с кучей просто ещё одна операция разыменования (а я обычно в начале цикла сразу беру указатель с итератора и работаю уже с ним), и всё упирается в то, как мы работаем с объектом.
Ну, идеального решения на все случаи в плюсах нету. Если вектор часто переносится - выгоднее, видимо, держать указатели. Если нет - объекты.
Тут, наверное, имелся в виду перенос данных в кэши процессора, когда ты последовательно обращаешься к непрерывному куску памяти, что намного ускоряет выполнение кода. А когда данные по памяти разбросаны по указателям, то прироста скорости не жди.