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

class Widget {

public:

Widget(Widget&& rhs) // rhs является rvalue-ссылкой

: name( std::move(rhs.name)),

p( std::move(rhs.p))

{ … }

…

private:

std::string name;

std::shared_ptr p;

};

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

class Widget f

public:

template

void setName(T&& newName) // newName является

{ name = std::forward(newName);} // универсальной ссылкой

};

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

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

class Widget {

public:

template

void setName( T&&newName) // Универсальная ссылка.

{ name = std::move(newName); } // Компилируется, но это

… // очень плохое решение!

private:

std::string name;

std::shared_ptr p;

};

std::string getWidgetName(); // Фабричная функция

Widget w;

auto n = getWidgetName(); // n - локальная переменная

w.setName(n); // Перемещение n в w!

// Значение n теперь неизвестно

Здесь локальная переменная nпередается функции w.setName. Вызывающий код можно простить за предположение о том, что эта функция по отношению к nявляется операцией чтения. Но поскольку setNameвнутренне использует std::moveдля безусловного приведения своего ссылочного параметра к rvalue, значение nможет быть перемещено в w.name, и nвернется из вызова setNameс неопределенным значением. Этот вид поведения может привести программиста к отчаянию — если не к прямому насилию.

Можно возразить, что setNameне должен был объявлять свой параметр как универсальную ссылку. Такие ссылки не могут быть константными (см. раздел 5.2), но setName, безусловно, не должен изменять свой параметр. Вы могли бы указать, что если перегрузить setNameдля константных значений lvalue и rvalue, то этой проблемы можно было бы избежать, например, таким образом:

class Widget {

public:

void setName( const std::string&newName) // Устанавливается

{ name = newName; } // из const lvalue

void setName( std::string&&newName) // Устанавливается

{ name = std::move(newName); } // из rvalue

};

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

w.setName("Adela Novak");

При наличии версии setName, принимающей универсальную ссылку, функции setNameбудет передан строковый литерал "Adela Novak", в котором он будет передан оператору присваивания для std::stringвнутри w. Таким образом, член-данные nameобъекта wбудет присвоен непосредственно из строкового литерала; никакого временного объекта std::stringсоздаваться не будет. Однако в случае перегруженных версий setNameбудет создан временный объект std::string, с которым будет связан параметр функции setName, и этот временный объект std::stringбудет перемещен в член-данные объекта w. Таким образом, вызов setNameповлечет за собой выполнение одного конструктора std::string(для создания временного объекта), одного перемещающего оператора присваивания std::string(для перемещения newNameв w.name) и одного деструктора std::string(для уничтожения временного объекта). Это практически наверняка более дорогостоящая последовательность операций, чем вызов только одного оператора присваивания std::string, принимающего указатель const char*. Дополнительная стоимость может варьироваться от реализации к реализации, и стоит ли беспокоиться о ней, зависит от приложения и библиотеки; однако, скорее всего, в ряде случаев замена шаблона, получающего универсальную ссылку, парой функций, перегруженных для lvalue- и rvalue-ссылок, приведет к дополнительным затратам времени выполнения.