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

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

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

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

До появления перемещающих операций копирование было основным способом переноса объектов, но для дорогостоящих ресурсов оно могло быть избыточным. C++11 добавил семантику перемещения и спецификатор noexcept, чтобы контейнеры могли безопасно использовать быстрые перемещающие операции.

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

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

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

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

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

Логика выбора обычно выглядит так:

если перемещение элемента не выбрасывает исключений, выбирается перемещение;
если перемещение может выбросить, но элемент можно копировать, выбирается копирование;
если копирование недоступно, используется перемещение даже при потенциальном исключении.

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

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

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

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

Минимальный пример:

#include <vector>
#include <string>

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

int main() {
    std::vector<Item> items;
    items.reserve(1);
    items.emplace_back();
    items.emplace_back(); // существующий Item можно переместить
}

Здесь noexcept сообщает контейнеру, что перемещение Item безопасно с точки зрения исключений. Если бы перемещение не было noexcept, а копирование оставалось доступным, реализация могла бы предпочесть копирование существующих элементов.

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

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

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

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

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

1. Достаточно ли добавить noexcept только к перемещающему конструктору?

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

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

2. Всегда ли std::vector обязан копировать элемент при потенциально бросающем перемещении?

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

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

3. Почему reserve не устраняет саму проблему выбора копирования или перемещения?

reserve уменьшает число перераспределений, но не меняет свойства типа. Если зарезервированной вместимости окажется недостаточно, при следующем расширении вектор снова должен будет перенести существующие элементы.

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