Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [76]

не изменится вызовом sign.setText, поскольку мы хотим использовать это значение при вызове signHistory.add. Следовательно, std::forward применяется только к последнему использованию универсальной ссылки.

Для std: :move применяются те же рассуждения (т.e. надо применить std::move к rvalue-ссылке только при ее последнем использовании), но важно отметить, что в некоторых редких случаях вы захотите вызвать std::move_if_noexcept вместо std::move. Чтобы узнать, когда и почему, обратитесь к разделу 3.8.

Если вы имеете дело с функцией, осуществляющей возврат по значению, и возвращаете объект, привязанный к rvalue-ссылке или универсальной ссылке, вы захотите применять std::move или std::forward при возврате ссылки. Чтобы понять, почему, рассмотрим функцию operator+ для сложения двух матриц, где о левой матрице точно известно, что она является rvalue (а следовательно, может повторно использовать свою память для хранения суммы матриц):

Matrix                  // Возврат по значению
operator+(Matrix&& lhs, const Matrix& rhs) {
 lhs += rhs;
 return std::move(lhs); // Перемещение lhs в
}                       // возвращаемое значение

С помощью приведения lhs к rvalue в инструкции return (с помощью std::move) lhs будет перемещен в местоположение возвращаемого функцией значения. Если опустить вызов std::move,

Matrix       // Как и ранее
operator+(Matrix&& lhs, const Matrix& rhs) {
 lhs += rhs;
 return lhs; // Копирование lhs в
}            // возвращаемое значение

то тот факт, что lhs представляет собой lvalue, заставит компиляторы вместо перемещения копировать его в местоположение возвращаемого функцией значения. В предположении, что тип Matrix поддерживает перемещающее конструирование, более эффективное, чем копирующее, применение std::move в инструкции return дает более эффективный код.

Если тип Matrix не поддерживает перемещения, приведение его к rvalue не повредит, поскольку rvalue будет просто скопировано копирующим конструктором Matrix (см. раздел 5.1). Если Matrix позже будет переделан так, что станет поддерживать перемещение, operator+ автоматически использует данное преимущество при следующей компиляции. В таком случае ничто не будет потеряно (и возможно, многое будет приобретено) при применении std::move к rvalue-ссылкам, возвращаемым из функций, которые осуществляют возврат по значению.

Для универсальных ссылок и std::forward ситуация схожа. Рассмотрим шаблон функции reduceAndCopy, который получает возможно сократимую дробь Fraction, сокращает ее, а затем возвращает копию сокращенной дроби. Если исходный объект представляет собой rvalue, его значение должно быть перенесено в возвращаемое значение (избегая тем самым стоимости создания копии), но если исходный объект — lvalue, должна быть создана фактическая копия:

template
Fraction                       // Возврат по значению
reduceAndCopy(T&& frac)        // Универсальная ссылка
{
 frac.reduce();
 return std::forward(frac); // Перемещение rvalue и
}                              // копирование lvalue в
                               // возвращаемое значение

Если опустить вызов std::forward, frac будет в обязательном порядке копироваться в возвращаемое значение reduceAndCopy.

Некоторые программисты берут приведенную выше информацию и пытаются распространить ее на ситуации, в которых она неприменима. Они рассуждают следующим образом: “если использование std::move для параметра, являющегося rvalue-ссылкой и копируемого в возвращаемое значение, превращает копирующий конструктор в перемещающий, то я могу выполнить ту же оптимизацию для возвращаемых мною локальных переменных”. Другими словами, они считают, что если дана функция, возвращающая локальную переменную по значению, такая, как следующая:

Widget makeWidget() // "Копирующая" версия makeWidget
{
 Widget w;          // Переменная
 …                  // Настройка w
 return w;          // "Копирование" w в возвращаемое значение
}

то они могут “оптимизировать” ее, превратив “копирование” в перемещение:

Widget makeWidget()  // Перемещающая версия makeWidget
{
 Widget w;
 …
 return std::move(w); // Перемещение w в возвращаемое
}                     // значение (не делайте этого!)

Мое обильное использование кавычек должно подсказать вам, что эти рассуждения не лишены недостатков. Но почему? Да потому что Комитет по стандартизации уже прошел этот путь и давно понял, что “копирующая” версия makeWidget может избежать необходимости копировать локальную переменную w, если будет создавать ее прямо в памяти, выделенной для возвращаемого значения функции. Это оптимизация, известная как оптимизация возвращаемого значения (return value optimization — RVO) и с самого начала благословленная стандартом С++.

Формулировка такого благословения — сложное дело, поскольку хочется разрешить такое отсутствие копирования только там, где оно не влияет на наблюдаемое поведение программы. Перефразируя излишне сухой текст стандарта, это благословение на отсутствие копирования (или перемещения) локального объекта[17] в функции, выполняющей возврат по значению, дается компиляторам, если (1) тип локального объекта совпадает с возвращаемым функцией и (2) локальный объект представляет собой возвращаемое значение. С учетом этого вернемся к “копирующей” версии