Краткий ответ

Если перемещающий конструктор элемента объявлен noexcept, std::vector обычно перемещает элементы при перераспределении памяти. Если перемещение потенциально может выбросить исключение, но доступно копирование, контейнер обычно выбирает копирование, чтобы сохранить сильную гарантию исключений.

Это делает noexcept у корректного перемещения не только документацией, но и важным фактором производительности контейнеров.

Исторический контекст

В C++11 появились перемещающие операции и спецификация noexcept. Они позволили эффективно передавать ресурсы без глубокого копирования, но создали проблему: перемещение само может завершиться исключением.

При перераспределении std::vector должен создать элементы в новом буфере, а затем уничтожить старые. Если перемещение части элементов выбросит исключение, исходные элементы могут оказаться уже изменёнными, поэтому контейнер не всегда сможет восстановить прежнее состояние.

Постановка проблемы

Представим тип, который дорого копировать, но его перемещающий конструктор не помечен noexcept. При увеличении ёмкости std::vector реализация предпочитает копирование, если оно доступно. Это сохраняет сильную гарантию исключений, но может привести к неожиданно дорогой операции.

Если копирование запрещено, контейнер вынужден перемещать элементы даже при потенциально бросающем перемещении. При исключении из такого перемещения гарантии для операции могут быть ослаблены: поведение зависит от требований конкретной операции и свойств типа, а стандарт для некоторых случаев указывает неопределённость эффектов.

Подробное решение

Упрощённая логика выбора похожа на std::move_if_noexcept: перемещение предпочтительно, когда оно гарантированно не выбрасывает исключения или когда копирование недоступно. Иначе выбирается копирование.

#include <vector>
#include <string>

struct Record {
    std::string data;
    Record(Record&&) noexcept = default;
    Record(const Record&) = default;
};

int main() {
    std::vector<Record> records;
    records.reserve(1);
    records.push_back(Record{"large payload"});
    records.push_back(Record{"another payload"});
}

В этом примере Record имеет noexcept-перемещение, поэтому при расширении records существующие элементы могут быть перемещены. Для std::string конкретная стоимость перемещения зависит от реализации и состояния строки, но контейнеру важно, что операция объявлена невыбрасывающей.

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

Для типа с пользовательским перемещающим конструктором полезно явно проверить это свойство через std::is_nothrow_move_constructible_v<T>. Также важно, чтобы невыбрасывающими были перемещающие операции всех содержащихся подобъектов; например, перемещение поля или базового класса может сделать перемещение всего типа потенциально бросающим.

reserve позволяет заранее уменьшить число перераспределений, но не устраняет саму необходимость корректно определять свойства перемещения. Кроме того, noexcept влияет не только на std::vector: аналогичный выбор встречается в других обобщённых алгоритмах и контейнерах стандартной библиотеки.

Ситуация из практики

В очереди обработки событий хранились объекты с буферами большого размера. Профилирование показало, что расширение вектора выполняло глубокое копирование, хотя разработчик ожидал дешёвого перемещения. Причиной был пользовательский перемещающий конструктор без noexcept, при этом копирование оставалось доступным.

Рассматривались три варианта:

увеличить начальную ёмкость через reserve: это уменьшает количество перераспределений, но не исправляет свойства типа;
запретить копирование: тогда вектор будет вынужден перемещать объекты, но исключение из перемещения может ослабить гарантии операции;
сделать перемещение действительно невыбрасывающим и объявить его noexcept: это сохраняет безопасный выбор вектора и устраняет лишние копии.

Выбрали третий вариант, предварительно проверив, что все ресурсы можно передавать без ошибок: владельцы буферов перемещались, а исходные объекты переводились в корректное валидное состояние. В результате при перераспределении исчезли глубокие копирования, а контракт типа стал точнее.

Что кандидаты часто упускают

Достаточно ли написать noexcept только у перемещающего конструктора?

Нет, важна фактическая корректность этой гарантии. Если перемещение объекта вызывает перемещение его поля, а поле может выбросить исключение, простое добавление noexcept приведёт к аварийному завершению при таком исключении. Обычно спецификацию делают условной или используют автоматически генерируемую спецификацию, если она отражает свойства подобъектов.

Всегда ли std::vector перемещает элементы, если тип некопируемый?

Он должен использовать перемещение, поскольку другого способа перенести элементы нет. Но отсутствие noexcept не исчезает: если такое перемещение выбросит исключение во время перераспределения, сильная гарантия может быть недоступна. Поэтому для некопируемых типов особенно важно проектировать перемещение как невыбрасывающее, когда это возможно.

Влияет ли noexcept на уже существующие элементы при push_back без перераспределения?

Нет, если свободная ёмкость уже есть, существующие элементы обычно не переносятся, поэтому данный выбор не возникает. noexcept становится существенным прежде всего при операциях, требующих перемещения элементов, например при перераспределении буфера std::vector или некоторых перестановках внутри обобщённых алгоритмов.