Вкачу-ка я свои пять копеек. Эта идиома нужна, чтобы обеспечить т.н. "strong exception safety guarantee". Это гарантия того, что операция не портит исходные объекты. Никогда. Они всегда всегда находятся в консистентном состоянии. В случае успеха вы получаете "новое хорошее" состояние. В случае неуспеха - "старое хорошее" (но обработку исключений ни кто не отменял). И исключает случай, когда старое "уже подпортили", а "новое недособрали". Зачем это? Почему не "ручками"? Ок, вот представьте, произошло исключение, вы пытаетесь вернуть объект в "хорошее" состояние, определяете "подпорченные части" и пытаетесь восстановить их, и ваша попытка "вдруг" генетит исключение. Тогда логика восстановления будет, мягко говоря, нетривиальной.

Что интересно, ранее контейнер ака vector такую гарантию ("strong exception safety guarantee") и предоставлял. Теперь (в новом стандарте) - нет, из-за появления movable семантики.

По примеру


swap может выбросить исключение, так что в этом примере может получиться "частично обменявшийся" вариант ...

Anatoly MoskovskyКак раз теперь, в стандарте С++11 swap над std объектами гарантировано не выбрасывает исключений.


Это очень легко проверить. Смотрим спецификацию (для >С++11)
http://en.cppreference.com/w/cpp/algorithm/swap


И видим, что swap не выбрасывает исключений тогда и __только__ __тогда__, когда не выбрасывают исключения movable-конструктор ("перемещающий" конструктор) и movable оператор присваивания ("перемещающий" оператор присваивания). Т.о., swap _НЕ_даёт гарантию отсутствия исключений.

Anatoly MoskovskyИ гарантии эти получили возможность предоставить как раз из-за появления movable.

Это утверждение я даже комментировать не буду. Movable-семантика позволила исключить дорогостоющую операцию копирования (дорогостоющую - как за счёт процессорного времени на её выполнение, так и дополнительной памяти под "лишнюю" переменную) во временный объект. Это сделало swap более быстрым на не-POD типах и менее требовательным к памяти. Но другой ценой: если раньше в процессе копирования во временную переменную происходило исключение, оно не "портило" оригинальные данные. Сейчас же появление исключения при перемещении (а не копировании, как было раньше) во временный объект __портит__ исходный объект, т.к. суть перемещения - "кража" содержимиого у одного объекта в пользу другого. Обращение "по старому имени" после выполнение move - в общем случае UB.

Anatoly MoskovskyТ.е. все строго наоборот по отношению к тому что вы сказали ))
Анатолий, вы поторопились. Всё наоборот как раз у Вас :)

Anatoly MoskovskyСпециально для вас выделяю то что вам не понятно
Anatoly Moskovskyswap над std объектами гарантировано не выбрасывает исключений.
Потому что std классы move_constructible и move_assignable.


Анатолий, не болтайте ерундой. Простейший пример (берём любую специализацию swap):
http://en.cppreference.com/w/cpp/utility/tuple/swap2


И так практически в каждой специализации. НУ НЕТ ТАМ гарантии - сплошные зависимости. Потому это зависит от реализации. Сделать STL "без выбрасывания исключений" под все платформы практически невозможно. Но некоторым можно попробовать утверждать, что std::tuple не из STL ...

Анатолий, вы Ваньку валяете?

- "Как раз теперь, в стандарте С++11 swap над std объектами гарантировано не выбрасывает исключений."
Именно в стандарте _ДО_ С++11 swap имел спецификафию throw(), т.е. пустую. К сожалению, это не соответствовало грубой действительности - там всё равно порождались исключения... Изменения в новом стандарте просто отразили этот факт.

Что гарантирует спецификация nothrow? Строго говоря - почти ничего. С её помощью _программист_ зуб даёт сообщает компилятору, что код не генерирует исключение. Благодаря этому компилятор может сделать некоторые оптимизации (прежде всего, на стеке). Если код заявлен как noexcept, но всё равно генерит исключение... Ок - это Ваша нога.

Далее. Исключение в swap могут бросать вызываемые там функции (о да, я КЭП). И новая спецификация это явным образом указывает. Мы уже посмотрели:
1. стандартный swap не объявлен как noexcept() - отражает зависимости от "нутра"
2. специализированный swap не объявлен как noexcept() - отражает зависимости
3. конструктор перемещения не объявлен как noexcept(). Можете заглянуть в пецификацию сами - мне лень сюда копипастить.
4. перемещающий оператор присваивания не объявлен как noexcept(). Можете заглянуть в пецификацию сами.

Разумеется, на каждый довод у Вас есть шанс попросить "копнуть глубже". Чтобы тянуть время и увиливать. Но всё куда проще.

Во-первых, можно сразу спуститься к "силикону". Что вы будете делать с аппаратным исключением? Куда "копать глубже"?

Во-вторых, вы сами признали, что сделать STL без исключений (в т.ч. для перемещающих конструкторов и операторов копирования) невозможно. Как же тогда вы собрались обеспечить noexcept swap, ведь его "безысключительность" полностью базируется на невыбрасывании исключений "нутром"?

В третьих, если стандарт что-то гарантирует, он это прописывает явным образом. Хотелось бы увидеть пункт стандарта (или его номер), который предоставляет эту гарантию , цитирую: " если все аргументы шаблонов - классы std то такие гарантии прямо следуют из стандарта."

Главное, чтобы топикстартеру польза была.