Першою моєю відповіддю було надзвичайно спрощене введення для переміщення семантики, і багато деталей було замислено спеціально, щоб зробити це просто. Однак для семантики зрушити ще багато, і я подумав, що настав час другої відповіді, щоб заповнити прогалини. Перша відповідь вже досить стара, і не здавалося правильним просто замінити її зовсім іншим текстом. Я думаю, що це все ще добре служить першим вступом. Але якщо ви хочете копати глибше, читайте далі :)
Стефан Т. Лававей знайшов час, щоб надати цінні відгуки. Дуже дякую, Стефане!
Вступ
Семантика переміщення дозволяє об’єкту за певних умов брати право власності на зовнішні ресурси якогось іншого об'єкта. Це важливо двома способами:
Перетворення дорогих копій в дешеві рухи. Дивіться для прикладу мою першу відповідь. Зауважте, що якщо об’єкт не керує хоча б одним зовнішнім ресурсом (безпосередньо чи опосередковано через об'єкти його учасника), семантика переміщення не надасть жодних переваг перед семантикою копіювання. У такому випадку копіювання об'єкта та переміщення об'єкта означає саме те саме:
class cannot_benefit_from_move_semantics
{
int a; // moving an int means copying an int
float b; // moving a float means copying a float
double c; // moving a double means copying a double
char d[64]; // moving a char array means copying a char array
// ...
};
Впровадження безпечних типів "лише для переміщення"; тобто типи, для яких копіювання не має сенсу, але переміщення робить. Приклади включають блокування, ручки файлів та розумні покажчики з унікальною семантикою власності. Примітка. У цій відповіді обговорюється std::auto_ptrзастарілий стандартний шаблон бібліотеки C ++ 98, який був замінений на std::unique_ptrC ++ 11. Проміжні програмісти C ++, мабуть, принаймні дещо знайомі std::auto_ptr, і через відображену "семантику переміщення" це здається гарною відправною точкою для обговорення семантики переміщення в C ++ 11. YMMV.
Що таке хід?
Стандартна бібліотека C ++ 98 пропонує розумний покажчик з унікальною семантикою власності std::auto_ptr<T>. У випадку, якщо ви не знайомі auto_ptr, його мета - гарантувати, що динамічно виділений об'єкт буде завжди випущений, навіть за умови винятків:
{
std::auto_ptr<Shape> a(new Triangle);
// ...
// arbitrary code, could throw exceptions
// ...
} // <--- when a goes out of scope, the triangle is deleted automatically
Незвичайне в тому auto_ptr, що вона "копіює" поведінку:
auto_ptr<Shape> a(new Triangle);
+---------------+
| triangle data |
+---------------+
^
|
|
|
+-----|---+
| +-|-+ |
a | p | | | |
| +---+ |
+---------+
auto_ptr<Shape> b(a);
+---------------+
| triangle data |
+---------------+
^
|
+----------------------+
|
+---------+ +-----|---+
| +---+ | | +-|-+ |
a | p | | | b | p | | | |
| +---+ | | +---+ |
+---------+ +---------+
Зверніть увагу , як ініціалізація bз aзовсім НЕ копіювати трикутник, але замість цього передає право власності на трикутнику від aдо b. Ми також говорять , що « aбуде переміщений в b " або "трикутник переміщається з a до b ». Це може здатися заплутаним, оскільки сам трикутник завжди залишається на тому самому місці в пам'яті.
Перемістити об’єкт означає передати право власності на якийсь ресурс, яким він управляє, на інший об’єкт.
Конструктор копій, auto_ptrмабуть, виглядає приблизно так (дещо спрощено):
auto_ptr(auto_ptr& source) // note the missing const
{
p = source.p;
source.p = 0; // now the source no longer owns the object
}
Небезпечні та нешкідливі рухи
Небезпечне в тому auto_ptr, що те, що синтаксично виглядає як копія, насправді є ходом. Спроба викликати функцію члена при переміщенні auto_ptrбуде викликати невизначене поведінку, тож вам слід бути дуже обережним, щоб не використовувати посилання auto_ptrпісля її переміщення з:
auto_ptr<Shape> a(new Triangle); // create triangle
auto_ptr<Shape> b(a); // move a into b
double area = a->area(); // undefined behavior
Але auto_ptrце не завжди небезпечно. Заводські функції - прекрасний випадок використання для auto_ptr:
auto_ptr<Shape> make_triangle()
{
return auto_ptr<Shape>(new Triangle);
}
auto_ptr<Shape> c(make_triangle()); // move temporary into c
double area = make_triangle()->area(); // perfectly safe
Зверніть увагу, як обидва приклади дотримуються однакової синтаксичної схеми:
auto_ptr<Shape> variable(expression);
double area = expression->area();
І все ж, одна з них посилається на невизначену поведінку, тоді як інша - ні. То яка різниця між виразами aта make_triangle()? Чи не вони обидва одного типу? Дійсно вони є, але вони мають різні ціннісні категорії .
Ціннісні категорії
Очевидно, що між виразом, aякий позначає auto_ptrзмінну, і виразом, make_triangle()який позначає виклик функції, яка повертає auto_ptrзначення, має бути деяка глибока різниця , що створює свіжий тимчасовий auto_ptrоб'єкт кожного разу, коли він викликається. aє прикладом значення , тоді як make_triangle()є прикладом ревальва .
Перехід від таких значень, як aнебезпечний, тому що ми могли б спробувати викликати функцію члена через a, посилаючись на невизначену поведінку. З іншого боку, перехід від таких значень, як make_triangle()цілком безпечний, оскільки після того, як конструктор копій зробив свою роботу, ми не можемо використовувати тимчасові знову. Не існує вираження, який би позначав сказане тимчасове; якщо ми просто make_triangle()знову напишемо , отримаємо інший тимчасовий. Насправді переміщений з тимчасового вже перейшов у наступний рядок:
auto_ptr<Shape> c(make_triangle());
^ the moved-from temporary dies right here
Зверніть увагу , що букви lі rмають історичне походження в стороні лівої руки і правої частини присвоювання. Це більше не відповідає дійсності для C ++, оскільки є значення, які не можуть з’являтися з лівої сторони завдання (наприклад, масиви або визначені користувачем типи без оператора присвоєння), і є rvalues, які можуть (усі rvalues типів класів з оператором призначення).
Оцінка типу класу - це вираз, оцінка якого створює тимчасовий об'єкт. За звичайних обставин жодне інше вираження всередині того самого діапазону не позначає той же тимчасовий об'єкт.
Rvalue посилання
Тепер ми розуміємо, що перехід від значень значення потенційно небезпечний, але переміщення з числа оцінок нешкідливий. Якщо C ++ мала мовну підтримку для відрізнення аргументів lvalue від аргументів rvalue, ми могли б або повністю заборонити перехід від lvalues, або принаймні зробити перехід від lvalues явним на сайті виклику, щоб ми більше не рухалися випадково.
Відповідь C ++ 11 на цю проблему - це релевантні посилання . Посилання на rvalue - це новий вид посилань, який пов'язується лише з rvalues, а синтаксис є X&&. Стара хороша довідка X&тепер відома як посилання на значення . (Зверніть увагу, що X&&це не посилання на посилання; у C ++ такого немає.)
Якщо ми кинемо constв суміш, у нас вже є чотири різних посилання. До яких типів виразів типу Xвони можуть зв’язатись?
lvalue const lvalue rvalue const rvalue
---------------------------------------------------------
X& yes
const X& yes yes yes yes
X&& yes
const X&& yes yes
На практиці можна забути const X&&. Бути обмеженим на читання з rvalues не дуже корисно.
Посилання на оцінку X&&- це новий вид посилань, який пов'язується лише з rvalues.
Неявні перетворення
Довідники Rvalue проходили через кілька версій. Починаючи з версії 2.1, посилання rvalue X&&також пов'язує всі категорії значень іншого типу за Yумови неявного перетворення з Yу X. У цьому випадку створюється тимчасовий тип X, і посилання rvalue пов'язане з тимчасовим:
void some_function(std::string&& r);
some_function("hello world");
У наведеному вище прикладі "hello world"є значення типу const char[12]. Оскільки відбувається неявна конверсія від const char[12]наскрізного const char*до std::string, створюється тимчасовий тип std::string, rякий пов'язаний з тимчасовим. Це один із випадків, коли відмінність між rvalues (виразами) та temporaries (об'єктами) трохи розмито.
Перемістіть конструктори
Корисним прикладом функції з X&&параметром є конструктор переміщення X::X(X&& source) . Його мета - передати право власності на керований ресурс від джерела до поточного об'єкта.
У C ++ 11 std::auto_ptr<T>було замінено, std::unique_ptr<T>що використовує переваги посилання rvalue. Я буду розробляти і обговорювати спрощену версію unique_ptr. По-перше, ми інкапсулюємо необроблений покажчик і перевантажимо операторів, ->і *тому наш клас відчуває себе вказівником:
template<typename T>
class unique_ptr
{
T* ptr;
public:
T* operator->() const
{
return ptr;
}
T& operator*() const
{
return *ptr;
}
Конструктор бере право власності на об'єкт, а деструктор видаляє його:
explicit unique_ptr(T* p = nullptr)
{
ptr = p;
}
~unique_ptr()
{
delete ptr;
}
Тепер приходить цікава частина конструктора ходу:
unique_ptr(unique_ptr&& source) // note the rvalue reference
{
ptr = source.ptr;
source.ptr = nullptr;
}
Цей конструктор переміщення робить саме те, що auto_ptrзробив конструктор копіювання, але він може постачатися лише з rvalues:
unique_ptr<Shape> a(new Triangle);
unique_ptr<Shape> b(a); // error
unique_ptr<Shape> c(make_triangle()); // okay
Другий рядок не вдається зібрати, тому що aце lvalue, але параметр unique_ptr&& sourceможе бути прив'язаний лише до rvalues. Це саме те, що ми хотіли; небезпечні рухи ніколи не повинні бути неявними. Третій рядок компілюється просто чудово, тому що make_triangle()це рецензія. Конструктор переміщення перенесе право власності від тимчасового до c. Знову ж таки, саме цього ми хотіли.
Конструктор переміщення передає право власності на керований ресурс поточному об'єкту.
Переміщення операторів призначення
Останній відсутній фрагмент - оператор присвоєння переміщення. Його завдання полягає у звільненні старого ресурсу та придбанні нового ресурсу зі свого аргументу:
unique_ptr& operator=(unique_ptr&& source) // note the rvalue reference
{
if (this != &source) // beware of self-assignment
{
delete ptr; // release the old resource
ptr = source.ptr; // acquire the new resource
source.ptr = nullptr;
}
return *this;
}
};
Зверніть увагу, як ця реалізація оператора призначення переміщення дублює логіку як деструктора, так і конструктора переміщення. Чи знайомі ви з ідіомою копіювання та заміни? Його також можна застосувати для переміщення семантики як ідіоми переміщення та заміни:
unique_ptr& operator=(unique_ptr source) // note the missing reference
{
std::swap(ptr, source.ptr);
return *this;
}
};
Тепер, що sourceє змінною типу unique_ptr, вона буде ініціалізована конструктором переміщення; тобто аргумент буде переміщено в параметр. Аргумент як і раніше повинен бути rvalue, оскільки сам конструктор переміщення має опорний параметр rvalue. Коли потік управління досягає закриває фігурну дужку operator=, sourceвиходить з області видимості, автоматично звільняючи старий ресурс.
Оператор призначення переміщення передає право власності на керований ресурс на поточний об'єкт, звільняючи старий ресурс. Ідіома переміщення та заміни спрощує реалізацію.
Перехід від значень
Іноді ми хочемо перейти від значень. Тобто, іноді ми хочемо, щоб компілятор ставився до lvalue так, як якщо б це було rvalue, тому він може викликати конструктор переміщення, хоча це може бути небезпечно. З цією метою C ++ 11 пропонує стандартний шаблон функції бібліотеки, який називається std::moveвсередині заголовка <utility>. Це ім'я трохи прикро, тому що std::moveпросто кидає value на rvalue; вона нічого не рухає сама по собі. Це просто дозволяє рухатись. Можливо, воно повинно було бути названим std::cast_to_rvalueабо std::enable_move, але ми до цього часу назріли.
Ось як явно ви переходите від значення lvalue:
unique_ptr<Shape> a(new Triangle);
unique_ptr<Shape> b(a); // still an error
unique_ptr<Shape> c(std::move(a)); // okay
Зауважте, що після третього рядка aбільше немає власного трикутника. Це нормально, тому що явно писати std::move(a), ми зробили наші наміри ясно: «Дорогий конструктора, робити все , що ви хочете з aдля ініціалізації c, я не дбаю про aбільше Чи не соромтеся , щоб мати свій шлях з. a.»
std::move(some_lvalue) кидає lvalue на rvalue, таким чином, даючи можливість наступного переміщення.
Xvalues
Зауважте, що хоч std::move(a)це і є ревальвація, його оцінка не створює тимчасового об'єкта. Ця загадка змусила комітет запровадити третю ціннісну категорію. Щось, що може бути пов'язане з посиланням на rvalue, навіть якщо воно не є rvalue у традиційному розумінні, називається xvalue (значення eXpiring). Традиційні rvalues були перейменовані на prvalues (Чисті rvalues).
І prvalues, і xvalues є rvalues. Xvalues і lvalues - це обидва glvalues (Узагальнені lvalues). Стосунки легше зрозуміти за допомогою діаграми:
expressions
/ \
/ \
/ \
glvalues rvalues
/ \ / \
/ \ / \
/ \ / \
lvalues xvalues prvalues
Зауважте, що лише xvalues дійсно нові; решта саме завдяки перейменуванню та групуванню.
C ++ 98 rvalues відомі як prvalues у C ++ 11. Подумки замініть всі випадки "rvalue" у попередніх пунктах на "prvalue".
Вихід із функцій
Поки ми спостерігали рух як в локальні змінні, так і в параметри функцій. Але рух можливий і в зворотному напрямку. Якщо функція повертається за значенням, деякий об'єкт на сайті виклику (можливо, локальна змінна або тимчасовий, але може бути будь-який тип об'єкта) ініціалізується з виразом після returnоператора як аргумент конструктору переміщення:
unique_ptr<Shape> make_triangle()
{
return unique_ptr<Shape>(new Triangle);
} \-----------------------------/
|
| temporary is moved into c
|
v
unique_ptr<Shape> c(make_triangle());
Можливо, дивно, що автоматичні об'єкти (локальні змінні, які не оголошені як static), також можуть бути неявно виведені з функцій:
unique_ptr<Shape> make_square()
{
unique_ptr<Shape> result(new Square);
return result; // note the missing std::move
}
Чому конструктор ходу приймає lvalue resultяк аргумент? Область дії resultвже закінчиться, і вона буде знищена під час розмотування стека. Після цього ніхто не міг поскаржитися, що resultякось змінилося; коли потік управління повертається у абонента, resultвже не існує! З цієї причини C ++ 11 має спеціальне правило, яке дозволяє повертати автоматичні об'єкти з функцій без необхідності запису std::move. Насправді, ви ніколи не повинні використовувати std::moveавтоматичні об'єкти для виведення з функцій, оскільки це гальмує "названу оптимізацію зворотного значення" (NRVO).
Ніколи не використовуйте std::moveдля переміщення автоматичних об'єктів з функцій.
Зауважте, що в обох заводських функціях тип повернення - це значення, а не посилання на значення. Посилання Rvalue все ще є посиланнями, і як завжди, ви ніколи не повинні повертати посилання на автоматичний об'єкт; абонент отримав би звичку, якщо ви обдурили компілятор у прийнятті вашого коду, наприклад:
unique_ptr<Shape>&& flawed_attempt() // DO NOT DO THIS!
{
unique_ptr<Shape> very_bad_idea(new Square);
return std::move(very_bad_idea); // WRONG!
}
Ніколи не повертайте автоматичні об'єкти за посиланням на rvalue. Переміщення виконується виключно конструктором переміщення, а не шляхом std::move, а не просто прив'язкою rvalue до посилання rvalue.
Перехід до членів
Рано чи пізно ви збираєтеся написати такий код:
class Foo
{
unique_ptr<Shape> member;
public:
Foo(unique_ptr<Shape>&& parameter)
: member(parameter) // error
{}
};
В основному, компілятор буде скаржитися, що parameterце значення. Якщо ви подивитесь на його тип, ви побачите посилання на оцінку rvalue, але посилання на rvalue просто означає "посилання, яке пов'язане з rvalue"; це не означає, що саме посилання є релевантним! Дійсно, parameterце просто звичайна змінна з назвою. Ви можете користуватися parameterякомога частіше всередині корпусу конструктора, і він завжди позначає один і той же об'єкт. Швидке переміщення від неї було б небезпечно, тому мова забороняє це.
Іменоване посилання rvalue - це значення, як і будь-яка інша змінна.
Рішення полягає в ручному включенні переміщення:
class Foo
{
unique_ptr<Shape> member;
public:
Foo(unique_ptr<Shape>&& parameter)
: member(std::move(parameter)) // note the std::move
{}
};
Ви можете стверджувати, що parameterбільше не використовується після ініціалізації member. Чому немає спеціального правила, щоб мовчки вставлятиstd::move само, як і значення повернення? Можливо, тому, що це буде занадто великим навантаженням на виконавці компілятора. Наприклад, що робити, якщо корпус конструктора знаходився в іншому блоці перекладу? На противагу цьому, правило повернення значення має просто перевірити таблиці символів, щоб визначити, чи відповідає ідентифікатор після того, як returnключове слово позначає автоматичний об'єкт.
Ви також можете передавати parameterзначення за значенням. Для таких типів, як лише для переміщенняunique_ptr , схоже, що ще немає встановленої ідіоми. Особисто я віддаю перевагу передачі за значенням, оскільки це викликає менше захаращення в інтерфейсі.
Спеціальні функції членів
C ++ 98 неявно оголошує три функції спеціальних членів на вимогу, тобто коли вони потрібні десь: конструктор копій, оператор присвоєння копії та деструктор.
X::X(const X&); // copy constructor
X& X::operator=(const X&); // copy assignment operator
X::~X(); // destructor
Довідники Rvalue проходили через кілька версій. Починаючи з версії 3.0, C ++ 11 оголошує дві додаткові функції спеціальних членів на вимогу: конструктор переміщення та оператор присвоєння переміщення. Зауважте, що ні VC10, ні VC11 не відповідають версії 3.0, тому вам доведеться їх реалізовувати самостійно.
X::X(X&&); // move constructor
X& X::operator=(X&&); // move assignment operator
Ці дві нові функції спеціальних членів декларуються лише неявно, якщо жодна з функцій спеціального члена не оголошується вручну. Крім того, якщо ви оголосите власного конструктора переміщення або оператора присвоєння переміщення, ні конструктор копій, ні оператор призначення копії не будуть оголошені неявно.
Що ці правила означають на практиці?
Якщо ви пишете клас без некерованих ресурсів, немає необхідності самостійно оголошувати будь-яку з п'яти спеціальних функцій учасників, і ви отримаєте правильну семантику копіювання та переміщення семантики безкоштовно. В іншому випадку вам доведеться самостійно реалізовувати функції спеціального члена. Звичайно, якщо ваш клас не має переваги в семантиці переміщення, немає необхідності в реалізації спеціальних операцій переміщення.
Зауважте, що оператор призначення копії та оператор присвоєння переміщення можуть бути об'єднані в єдиний об'єднаний оператор присвоєння, приймаючи його аргумент за значенням:
X& X::operator=(X source) // unified assignment operator
{
swap(source); // see my first answer for an explanation
return *this;
}
Таким чином, кількість спеціальних функцій членів для реалізації крапель з п'яти до чотирьох. Тут є компроміс між безпекою та винятком винятків, але я не є експертом у цьому питанні.
Пересилання посилань ( раніше відомих як Універсальні посилання )
Розглянемо наступний шаблон функції:
template<typename T>
void foo(T&&);
Ви можете розраховувати T&&на прив’язку лише до значень, оскільки на перший погляд це виглядає як посилання на оцінку. Як виявляється, хоча, T&&також прив'язується до значень:
foo(make_triangle()); // T is unique_ptr<Shape>, T&& is unique_ptr<Shape>&&
unique_ptr<Shape> a(new Triangle);
foo(a); // T is unique_ptr<Shape>&, T&& is unique_ptr<Shape>&
Якщо аргумент є ревальваційним типом X, Tвиводиться, щоб бути X, значить, T&&означає X&&. Це те, що хтось очікував. Але якщо аргумент є типовим значенням X, обумовленим спеціальним правилом, Tвипливає X&, T&&що означає щось подібне X& &&. Але так як C ++ до сих пір поняття не має посилань на посилання, тип X& &&буде зруйнувалася в X&. Спочатку це може здатися заплутаним і марним, але згортання посилань має важливе значення для ідеального пересилання (про що тут мова не піде).
T&& - це не релевантна посилання, а посилання на переадресацію. Він також зв'язується з lvalues, в якому випадку Tі T&&обидва Lvalue посилання.
Якщо ви хочете обмежити шаблон функції до значень, ви можете комбінувати SFINAE з ознаками типу:
#include <type_traits>
template<typename T>
typename std::enable_if<std::is_rvalue_reference<T&&>::value, void>::type
foo(T&&);
Здійснення ходу
Тепер, коли ви розумієте згортання посилань, ось як std::moveреалізовано:
template<typename T>
typename std::remove_reference<T>::type&&
move(T&& t)
{
return static_cast<typename std::remove_reference<T>::type&&>(t);
}
Як бачите, moveприймає будь-який параметр завдяки посиланню на переадресацію T&&, і він повертає посилання rvalue. std::remove_reference<T>::typeВиклик мета-функція необхідна , так як в противному випадку, для lvalues типу X, тип повертається б X& &&, що б впасти в X&. Оскільки tзавжди є значення lvalue (пам’ятайте, що названа посилання rvalue є рівнем lvalue), але ми хочемо прив’язати tдо посилання rvalue, ми повинні явно tпередати правильний тип повернення. Виклик функції, що повертає посилання rvalue, сам по собі є xvalue. Тепер ви знаєте, звідки беруться xvalues;)
Виклик функції, яка повертає посилання rvalue, наприклад std::move, xvalue.
Зауважте, що повернення за допомогою посилання rvalue добре в цьому прикладі, оскільки tне позначає автоматичний об'єкт, а замість цього об'єкт, переданий абонентом.