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

Однако наиболее серьезной проблемой с перегрузкой для lvalue и rvalue является не объем или идиоматичность исходного кода и не производительность времени выполнения. Это — плохая масштабируемость проекта. Widget::setNameпринимает только один параметр, так что необходимы только две перегрузки. Но для функций, принимающих большее количество параметров, каждый из которых может быть как lvalue, так и rvalue, количество перегрузок растет в соответствии с показательной функцией: n параметров требуют 2 ⁿ перегрузок. И это еще не самый худший случай. Некоторые функции (на самом деле — шаблоны функций) принимают неограниченное количество параметров, каждый из которых может быть как lvalue, так и rvalue. Типичными представителями таких функций являются std::make_sharedи, начиная с С++14, std::make_unique(см. раздел 4.4). Попробуйте написать объявления их наиболее часто используемых перегрузок:

template // Из стандарта C++11

shared_ptr make_shared( Args&&...args);

template // Из стандарта С++14

unique_ptr make_unique( Args&&...args);

Для функций наподобие указанных перегрузка для lvalue и rvalue не является приемлемым вариантом: единственным выходом является применение универсальных ссылок. А внутри таких функций, уверяю вас, к универсальным ссылкам при их передаче другим функциям следует применять std::forward. Вот то, что вы должны делать.

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

template // text - универсальная

void setSignText(T&& text) // ссылка

{

sign.setText( text); // Используем text, но не

// изменяем его

auto now = // Получение текущего времени

std::chrono::system_clock::now();

signHistory.add(now,

std::forward( text)); // Условное приведение

} // text к rvalue

Здесь мы хотим гарантировать, что значение textне изменится вызовом 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) и с самого начала благословленная стандартом С++.