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