С++, почему в контексте конструкторов перемещения и операторов присваивания перемещения требуется noexcept для включения оптимизации?

Особая важность noexcept конструкторов перемещения и операторов присваивания подробно объясняется в https://vimeo.com/channels/ndc2014/97337253

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

Например, когда вы делаете push_back(t) для вектора, если вектор заполнен (size() == capacity()), тогда ему необходимо выделить новый блок памяти и скопировать все существующие элементы в новую память. Если копирование любого из элементов вызывает исключение, библиотека просто уничтожает все созданные ею элементы в новом хранилище и освобождает новую память, оставляя исходный вектор неизменным (таким образом, выполняется строгая гарантия безопасности исключений). Было бы быстрее переместить существующие элементы в новое хранилище, но если бы перемещение могло вызвать выброс, то любые уже перемещенные элементы уже были бы изменены, и выполнение строгой гарантии было бы невозможно, поэтому библиотека будет пытаться переместить их только тогда, когда он знает, что не может бросить, что он может знать, только если они noexcept.

ИМХО, использование noexcept само по себе не включит оптимизацию компилятора. В STL есть трейты:

std::is_nothrow_move_constructible
std::is_nothrow_move_assignable

Контейнеры STL, такие как vector и т. д., используют эти черты для проверки типа T и используют конструкторы перемещения и присваивания вместо конструкторов копирования и присваивания.

Почему STL использует эти черты вместо:

std::is_move_constructible
std::is_move_assignable

Ответ: обеспечить сильную гарантию исключения.

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

Оптимизация может быть выполнена различными способами. Автоматически компилятором, а также различными реализациями кода, использующими ваши конструкторы и оператор присваивания. Взгляните на STL, есть некоторые специализации для кода, которые отличаются, если вы используете исключения или нет, которые реализуются через признаки типа.

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

Тут тоже возник вопрос: noexcept, раскрутка стека и производительность

Может быть, ваш вопрос дублирует этот?

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

Какова цель noexcept здесь?

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