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

Я так же озадачен этим вопросом.

Насколько я могу судить, лучшая современная идиома состоит в том, чтобы разделить передачу по значению на пару передач по ссылке.

template< typename t >
std::decay_t< t >
val( t && o ) // Given an object, return a new object "val"ue by move or copy
    { return std::forward< t >( o ); }

Result processBigData(BigData && in_rref) {
    // implementation
}

Result processBigData(BigData const & in_cref ) {
    return processBigData( val( in_cref ) );
}

Конечно, фрагменты аргумента могли быть перемещены перед исключением. Проблема распространяется на любые вызовы processBigData.

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

Судя по всему, этот вопрос активно обсуждался на недавней конференции CppCon 2014. Херб Саттер резюмировал последние новости в своем заключительном докладе Назад к основам! Основы современного стиля C++ (слайды).

Его вывод довольно прост: Не используйте передачу по значению для аргументов приемника.

Аргументы в пользу использования этого метода в первую очередь (как популяризировалось Эриком Ниблером на конференции Meeting C++ 2013, Дизайн библиотеки C++11 (слайды)), кажется, перевешивают недостатки. Первоначальная мотивация для передачи аргументов приемника по значению состояла в том, чтобы избавиться от комбинаторного взрыва для перегрузок функций, который возникает в результате использования const&/&&.

К сожалению, кажется, что это влечет за собой ряд непредвиденных последствий. Одним из них являются потенциальные недостатки эффективности (в основном из-за ненужного выделения буфера). Другая проблема с безопасностью исключений из этого вопроса. Оба они обсуждаются в докладе Херба.

Херб пришел к выводу, что не использовать передачу по значению для аргументов приемника, а вместо этого полагаться на отдельные const&/&& (при этом const& используется по умолчанию, а && зарезервировано для тех немногих случаев, когда требуется оптимизация).

Это также соответствует тому, что предложил ответ @Potatoswatter. Передавая аргумент приемника через &&, мы могли бы отложить фактическое перемещение данных из аргумента до момента, когда мы можем дать гарантию отсутствия исключений.

Мне понравилась идея передачи аргументов стока по значению, но, похоже, на практике она работает не так хорошо, как все надеялись.

Обновление после пяти лет размышлений об этом:

Теперь я убежден, что мой мотивирующий пример — неправильное использование семантики ходов. После вызова processBigData(std::move(b)); мне ни в коем случае нельзя позволять предположить, в каком состоянии находится b, даже если функция завершается с исключением. Это приводит к коду, за которым трудно следить и поддерживать.

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

class BigDataException : public std::runtime_error {
private:
    BigData b;
public:
    BigData retrieveDataAfterError() &&;

    // [...]
};


BigData b = retrieveData();
Result r;
try {
    r = processBigData(std::move(b));
} catch(BigDataException& e) {
    b = std::move(e).retrieveDataAfterError();
    r = fixEnvironmnentAndTryAgain(std::move(b));
}

Если я хочу восстановить содержимое b, мне нужно явно передать его по пути ошибки (в данном случае завернуто внутрь BigDataException). Этот подход требует немного дополнительного шаблона, но он более идиоматичен, поскольку не требует делать предположения о состоянии перемещаемого объекта.