Что такое семантика перемещения?

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

#include <cstring>
#include <algorithm>

class string
{
    char* data;

public:

    string(const char* p)
    {
        size_t size = std::strlen(p) + 1;
        data = new char[size];
        std::memcpy(data, p, size);
    }

Поскольку мы сами решили управлять памятью, нам нужно следовать правилу трех < / а>. Я собираюсь отложить написание оператора присваивания и пока реализую только деструктор и конструктор копирования:

    ~string()
    {
        delete[] data;
    }

    string(const string& that)
    {
        size_t size = std::strlen(that.data) + 1;
        data = new char[size];
        std::memcpy(data, that.data, size);
    }

string a(x);                                    // Line 1
string b(x + y);                                // Line 2
string c(some_function_returning_a_string());   // Line 3

    string(string&& that)   // string&& is an rvalue reference to a string
    {
        data = that.data;
        that.data = nullptr;
    }

Поздравляем, теперь вы понимаете основы семантики перемещения! Продолжим реализацию оператора присваивания. Если вы не знакомы с идиомой копирования и обмена, изучите ее. и вернитесь, потому что это потрясающая идиома C ++, связанная с безопасностью исключений.

    string& operator=(string that)
    {
        std::swap(data, that.data);
        return *this;
    }
};

А, вот и все? "Где ссылка на rvalue?" вы можете спросить. "Нам это здесь не нужно!" это мой ответ :)

Обратите внимание, что мы передаем параметр that по значению, поэтому that необходимо инициализировать, как и любой другой строковый объект. Как именно будет инициализироваться that? В былые времена C ++ 98 ответом было бы "по копии конструктор". В C ++ 0x компилятор выбирает между конструктором копирования и конструктором перемещения в зависимости от того, является ли аргумент оператора присваивания lvalue или rvalue.

Итак, если вы скажете a = b, конструктор копирования инициализирует that (поскольку выражение b является lvalue), а оператор присваивания меняет местами содержимое только что созданной глубокой копии. Это само определение идиомы копирования и обмена - сделать копию, поменять местами содержимое копией, а затем избавиться от копии, покинув область видимости. Здесь ничего нового.

Но если вы скажете a = x + y, конструктор перемещения инициализирует that (потому что выражение x + y является rvalue), поэтому глубокая копия не задействуется, только эффективное перемещение. that по-прежнему является независимым от аргумента объектом, но его построение было тривиальным, поскольку данные кучи не нужно было копировать, а просто перемещать. Копировать его не было необходимости, потому что x + y - это rvalue, и, опять же, можно перейти от строковых объектов, обозначенных rvalues.

Подводя итог, конструктор копирования делает глубокую копию, потому что источник должен оставаться нетронутым. Конструктор перемещения, с другой стороны, может просто скопировать указатель, а затем установить указатель в источнике на null. Это нормально, чтобы «обнулить» исходный объект таким образом, потому что у клиента нет возможности проверить объект снова.

Я надеюсь, что этот пример уловил суть. Есть гораздо больше возможностей rvalue ссылок и семантики перемещения, которые я намеренно упустил, чтобы не усложнять. Если вам нужна дополнительная информация, см. мой дополнительный ответ.

Моим первым ответом было чрезвычайно упрощенное введение в семантику перемещения, и многие детали были упущены специально, чтобы не усложнять. Тем не менее, есть еще много чего для изменения семантики, и я подумал, что пришло время для второго ответа, чтобы заполнить пробелы. Первый ответ уже довольно старый, и было нецелесообразно просто заменять его совершенно другим текстом. Я думаю, что он по-прежнему служит первым знакомством. Но если хотите копнуть глубже, читайте дальше :)

Стефан Т. Лававей нашел время, чтобы дать ценный отзыв. Большое спасибо, Стефан!

Вступление

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

1. Превращение дорогих копий в дешевые ходы. См. Мой первый ответ для примера. Обратите внимание, что если объект не управляет хотя бы одним внешним ресурсом (прямо или косвенно через его объекты-члены), семантика перемещения не даст никаких преимуществ перед семантикой копирования. В этом случае копирование объекта и перемещение объекта означают одно и то же:

   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
   
       // ...
   };
   

2. Реализация безопасных типов «только для перемещения»; то есть типы, для которых копирование не имеет смысла, а перемещение имеет смысл. Примеры включают блокировки, дескрипторы файлов и интеллектуальные указатели с уникальной семантикой владения. Примечание. В этом ответе обсуждается std::auto_ptr, устаревший шаблон стандартной библиотеки C ++ 98, который был заменен на std::unique_ptr в C ++ 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 - это пример lvalue, а make_triangle() - пример rvalue.

Переход от lvalues, таких как a, опасен, потому что позже мы могли бы попытаться вызвать функцию-член через a, вызывая неопределенное поведение. С другой стороны, переход от значений rvalue, таких как make_triangle(), совершенно безопасен, потому что после того, как конструктор копирования выполнил свою работу, мы не можем снова использовать временное значение. Нет выражения, которое обозначает указанное временное; если мы просто снова напишем make_triangle(), мы получим другое временное. Фактически, перемещенный временный объект уже пропал в следующей строке:

auto_ptr<Shape> c(make_triangle());
                                  ^ the moved-from temporary dies right here

Обратите внимание, что буквы l и r имеют историческое происхождение в левой и правой частях задания. Это больше не верно в C ++, потому что есть l-значения, которые не могут отображаться в левой части присваивания (например, массивы или определяемые пользователем типы без оператора присваивания), и есть r-значения, которые могут (все r-значения типов классов с оператором присваивания).

Значение типа класса - это выражение, при вычислении которого создается временный объект. При нормальных обстоятельствах никакое другое выражение в той же области видимости не обозначает тот же временный объект.

Ссылки на Rvalue

Теперь мы понимаем, что переход от lvalues ​​потенциально опасен, но переход от rvalues ​​безвреден. Если бы в C ++ была языковая поддержка, позволяющая отличать аргументы lvalue от аргументов rvalue, мы могли бы либо полностью запретить переход от lvalue, либо, по крайней мере, сделать переход от lvalues ​​явным на месте вызова, чтобы мы больше не перемещались случайно.

Ответом C ++ 11 на эту проблему являются ссылки на rvalue. Ссылка rvalue - это новый вид ссылки, который привязывается только к rvalue, и имеет синтаксис X&&. Старая добрая ссылка X& теперь известна как ссылка lvalue. (Обратите внимание, что 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 ​​не очень полезно.

Ссылка rvalue X&& - это новый вид ссылки, который привязывается только к rvalue.

Неявные преобразования

Ссылки на Rvalue прошли несколько версий. Начиная с версии 2.1, ссылка rvalue X&& также привязывается ко всем категориям значений другого типа Y при условии неявного преобразования из Y в X. В этом случае создается временный объект типа X, и ссылка rvalue привязывается к этому временному объекту:

void some_function(std::string&& r);

some_function("hello world");

В приведенном выше примере "hello world" - это l-значение типа const char[12]. Поскольку существует неявное преобразование из const char[12] через const char* в std::string, создается временный объект типа std::string, и r привязан к этому временному объекту. Это один из случаев, когда различие между rvalue (выражениями) и временными значениями (объектами) немного размыто.

Конструкторы перемещения

Полезным примером функции с параметром 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, но он может быть предоставлен только с rvalue:

unique_ptr<Shape> a(new Triangle);
unique_ptr<Shape> b(a);                 // error
unique_ptr<Shape> c(make_triangle());   // okay

Вторая строка не может быть скомпилирована, потому что a является lvalue, но параметр unique_ptr&& source может быть привязан только к rvalue. Это именно то, что мы хотели; опасные ходы никогда не должны подразумеваться. Третья строка компилируется отлично, потому что make_triangle() - это rvalue. Конструктор перемещения передаст право владения от временного к 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 выходит из области видимости, автоматически освобождая старый ресурс.

Оператор присваивания перемещения передает владение управляемым ресурсом текущему объекту, освобождая старый ресурс. Идиома перемещения и замены упрощает реализацию.

Переход от lvalues

Иногда мы хотим перейти от lvalues. То есть иногда мы хотим, чтобы компилятор обрабатывал lvalue, как если бы это было rvalue, чтобы он мог вызывать конструктор перемещения, даже если это может быть потенциально небезопасным. Для этой цели C ++ 11 предлагает шаблон стандартной библиотечной функции под названием std::move внутри заголовка <utility>. Это имя немного неудачно, потому что std::move просто преобразует lvalue в 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, даже если это не rvalue в традиционном смысле, называется xvalue (eXpiring value). Традиционные rvalues ​​были переименованы в prvalues ​​ (чистые rvalues).

И prvalues, и xvalues ​​являются rvalue. Оба значения Xvalues ​​и lvalue являются glvalues ​​ (обобщенные lvalue). Отношения легче понять с помощью диаграммы:

        expressions
          /     \
         /       \
        /         \
    glvalues   rvalues
      /  \       /  \
     /    \     /    \
    /      \   /      \
lvalues   xvalues   prvalues

Обратите внимание, что только значения x действительно новы; остальное просто связано с переименованием и группировкой.

Rvalue C ++ 98 известны как 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. Ссылки 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 - это lvalue. Если вы посмотрите на его тип, вы увидите ссылку на rvalue, но ссылка на rvalue просто означает «ссылку, которая привязана к rvalue»; это не означает, что сама ссылка является rvalue! Действительно, parameter - это просто обычная переменная с именем. Вы можете использовать parameter сколь угодно часто внутри тела конструктора, и он всегда обозначает один и тот же объект. Неявно отходить от него было бы опасно, поэтому язык запрещает это.

Именованная ссылка rvalue - это lvalue, как и любая другая переменная.

Решение состоит в том, чтобы вручную включить перемещение:

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;
}

Таким образом, количество реализуемых специальных функций-членов сокращается с пяти до четырех. Здесь есть компромисс между безопасностью исключений и эффективностью, но я не эксперт в этом вопросе.

Ссылки на пересылку (ранее известные как < em> Универсальные ссылки)

Рассмотрим следующий шаблон функции:

template<typename T>
void foo(T&&);

Вы могли ожидать, что T&& будет связываться только с rvalue, потому что на первый взгляд это выглядит как ссылка на rvalue. Однако оказывается, что T&& также связывается с lvalues:

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>&

Если аргумент является r-значением типа X, T выводится как X, следовательно, T&& означает X&&. Это то, чего можно было ожидать. Но если аргумент является lvalue типа X, по особому правилу T выводится как X&, следовательно, T&& будет означать что-то вроде X& &&. Но поскольку C ++ по-прежнему не имеет понятия ссылок на ссылки, тип X& && свернут в X&. Поначалу это может показаться запутанным и бесполезным, но сворачивание ссылок необходимо для точной пересылки (что здесь не обсуждается).

T && - это не ссылка на rvalue, а ссылка на пересылку. Он также связывается с lvalue, и в этом случае T и T&& являются ссылками на lvalue.

Если вы хотите ограничить шаблон функции значениями rvalue, вы можете объединить 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 необходим, потому что в противном случае для lvalue типа X тип возврата был бы X& &&, который свернулся бы в X&. Поскольку t всегда является lvalue (помните, что именованная ссылка rvalue - это lvalue), но мы хотим привязать t к ссылке rvalue, мы должны явно привести t к правильному возвращаемому типу. Вызов функции, возвращающей ссылку на rvalue, сам по себе является xvalue. Теперь вы знаете, откуда берутся значения x;)

Вызов функции, возвращающей ссылку на rvalue, например std::move, является xvalue.

Обратите внимание, что возврат по ссылке rvalue в этом примере прекрасен, потому что t не обозначает автоматический объект, а вместо этого объект, который был передан вызывающей стороной.

Предположим, у вас есть функция, которая возвращает существенный объект:

Matrix multiply(const Matrix &a, const Matrix &b);

Когда вы пишете такой код:

Matrix r = multiply(a, b);

тогда обычный компилятор C ++ создаст временный объект для результата multiply(), вызовет конструктор копирования для инициализации r, а затем уничтожит временное возвращаемое значение. Семантика перемещения в C ++ 0x позволяет вызывать «конструктор перемещения» для инициализации r путем копирования его содержимого, а затем отбрасывать временное значение без необходимости его уничтожения.

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

Если вас действительно интересует хорошее и подробное объяснение семантики перемещения, я настоятельно рекомендую прочитать исходную статью о них, " Предложение о добавлении поддержки семантики перемещения в язык C ++ "

Он очень доступен и легко читается, и это отличный пример преимуществ, которые они предлагают. Есть и другие более свежие и актуальные документы о семантике перемещения, доступные на Веб-сайт WG21, но этот, вероятно, самый простой, поскольку он подходит к вещам с точки зрения верхнего уровня и не вникает в подробности языка.

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

В C ++ 03 объекты часто копируются только для уничтожения или присвоения, прежде чем какой-либо код снова использует значение. Например, когда вы возвращаетесь по значению из функции - если RVO не срабатывает - возвращаемое вами значение копируется в кадр стека вызывающего объекта, а затем выходит за пределы области видимости и уничтожается. Это лишь один из многих примеров: см. Передачу по значению, когда исходный объект является временным, такие алгоритмы, как sort, которые просто переупорядочивают элементы, перераспределение в vector, когда его capacity() превышено, и т. Д.

Когда такие пары копирования / уничтожения дороги, обычно это связано с тем, что объект владеет каким-то тяжелым ресурсом. Например, vector<string> может владеть динамически выделяемым блоком памяти, содержащим массив из string объектов, каждый со своей собственной динамической памятью. Копирование такого объекта обходится дорого: вам нужно выделить новую память для каждого динамически выделяемого блока в источнике и скопировать все значения. Затем вам нужно освободить всю память, которую вы только что скопировали. Однако перемещение большого vector<string> означает просто копирование нескольких указателей (которые относятся к блоку динамической памяти) в место назначения и их обнуление в источнике.

Простыми (практичными) терминами:

Копирование объекта означает копирование его «статических» членов и вызов оператора new для его динамических объектов. Верно?

class A
{
   int i, *p;

public:
   A(const A& a) : i(a.i), p(new int(*a.p)) {}
   ~A() { delete p; }
};

Однако переместить объект (повторяю, с практической точки зрения) подразумевает только копирование указателей динамических объектов, а не создание новых.

Но разве это не опасно? Конечно, вы можете дважды уничтожить динамический объект (ошибка сегментации). Итак, чтобы избежать этого, вы должны "сделать недействительными" указатели источника, чтобы избежать их двойного уничтожения:

class A
{
   int i, *p;

public:
   // Movement of an object inside a copy constructor.
   A(const A& a) : i(a.i), p(a.p)
   {
     a.p = nullptr; // pointer invalidated.
   }

   ~A() { delete p; }
   // Deleting NULL, 0 or nullptr (address 0x0) is safe. 
};

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

void heavyFunction(HeavyType());

В этой ситуации создается анонимный объект, затем копируется в параметр функции, а затем удаляется. Итак, здесь лучше переместить объект, потому что вам не нужен анонимный объект, и вы можете сэкономить время и память.

Это приводит к концепции ссылки "rvalue". Они существуют в C ++ 11 только для того, чтобы определять, является ли полученный объект анонимным. Я думаю, вы уже знаете, что «lvalue» - это присваиваемая сущность (левая часть оператора =), поэтому вам нужна именованная ссылка на объект, чтобы иметь возможность действовать как lvalue. Rvalue - это с точностью до наоборот, объект без именованных ссылок. По этой причине анонимный объект и rvalue являются синонимами. Так:

class A
{
   int i, *p;

public:
   // Copy
   A(const A& a) : i(a.i), p(new int(*a.p)) {}

   // Movement (&& means "rvalue reference to")
   A(A&& a) : i(a.i), p(a.p)
   {
      a.p = nullptr;
   }

   ~A() { delete p; }
};

В этом случае, когда объект типа A должен быть «скопирован», компилятор создает ссылку lvalue или ссылку rvalue в зависимости от того, назван переданный объект или нет. В противном случае вызывается ваш конструктор перемещения, и вы знаете, что объект является временным, и вы можете перемещать его динамические объекты вместо их копирования, экономя место и память.

Важно помнить, что «статические» объекты всегда копируются. Нет способов «переместить» статический объект (объект в стеке, а не в куче). Таким образом, различие «перемещение» / «копирование», когда объект не имеет динамических членов (прямо или косвенно), не имеет значения.

Если ваш объект сложен, а деструктор имеет другие побочные эффекты, такие как вызов функции библиотеки, вызов других глобальных функций или что-то еще, возможно, лучше сигнализировать о движении с помощью флага:

class Heavy
{
   bool b_moved;
   // staff

public:
   A(const A& a) { /* definition */ }
   A(A&& a) : // initialization list
   {
      a.b_moved = true;
   }

   ~A() { if (!b_moved) /* destruct object */ }
};

Итак, ваш код короче (вам не нужно делать nullptr присваивание каждому динамическому члену) и более общий.

Другой типичный вопрос: в чем разница между A&& и const A&&? Конечно, в первом случае можно доработать объект, а во втором - нет, но, практический смысл? Во втором случае вы не можете его изменить, поэтому у вас нет способов сделать объект недействительным (кроме как с помощью изменяемого флага или чего-то подобного), и нет практической разницы в конструкторе копирования.

А что такое идеальная пересылка? Важно знать, что «ссылка rvalue» - это ссылка на именованный объект в «области действия вызывающего объекта». Но в фактической области действия ссылка rvalue - это имя объекта, поэтому она действует как именованный объект. Если вы передаете ссылку rvalue на другую функцию, вы передаете именованный объект, поэтому объект не получен как временный объект.

void some_function(A&& a)
{
   other_function(a);
}

Объект a будет скопирован в фактический параметр other_function. Если вы хотите, чтобы объект a продолжал обрабатываться как временный объект, вы должны использовать функцию std::move:

other_function(std::move(a));

В этой строке std::move приведет a к значению r, а other_function получит объект как безымянный объект. Конечно, если other_function не имеет специальной перегрузки для работы с безымянными объектами, это различие не важно.

Это идеальная пересылка? Нет, но мы очень близки. Идеальная пересылка полезна только для работы с шаблонами, чтобы сказать: если мне нужно передать объект другой функции, мне нужно, чтобы, если я получаю именованный объект, объект передается как именованный объект, а когда нет, Я хочу передать его как безымянный объект:

template<typename T>
void some_function(T&& a)
{
   other_function(std::forward<T>(a));
}

Это сигнатура прототипной функции, использующей идеальную пересылку, реализованную в C ++ 11 с помощью std::forward. Эта функция использует некоторые правила создания экземпляров шаблона:

 `A& && == A&`
 `A&& && == A&&`

Итак, если T является lvalue ссылкой на A (T = A &), a также (A & && => A &). Если T является ссылкой rvalue на A, a также (A && && => A &&). В обоих случаях a является именованным объектом в фактической области действия, но T содержит информацию о его «ссылочном типе» с точки зрения области действия вызывающего объекта. Эта информация (T) передается как параметр шаблона в forward, и 'a' перемещается или нет в соответствии с типом T.

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

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

Семантика перемещения - это в основном определяемый пользователем тип с конструктором, который принимает ссылку на r-значение (новый тип ссылки с использованием && (да, два амперсанда)), который не является константой, это называется конструктором перемещения, то же самое касается оператора присваивания. Итак, что делает конструктор перемещения: вместо того, чтобы копировать память из исходного аргумента, он «перемещает» память из источника в место назначения.

Когда бы вы хотели это сделать? ну std :: vector - это пример, скажем, вы создали временный std :: vector и возвращаете его из функции, скажем:

std::vector<foo> get_foos();

У вас будут накладные расходы от конструктора копирования, когда функция вернется, если (а это будет в С ++ 0x) std :: vector имеет конструктор перемещения вместо копирования, он может просто установить его указатели и `` перемещать '' динамически выделенный память на новый экземпляр. Это похоже на семантику передачи права собственности с std :: auto_ptr.

Чтобы проиллюстрировать необходимость семантики перемещения, давайте рассмотрим этот пример без семантики перемещения:

Вот функция, которая принимает объект типа T и возвращает объект того же типа T:

T f(T o) { return o; }
  //^^^ new object constructed

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

T b = f(a);
  //^ new object constructed

Два новых объекта были созданы, один из которых является временным объектом, который используется только на время выполнения функции.

Когда новый объект создается из возвращаемого значения, вызывается конструктор копирования, чтобы скопировать содержимое временного объекта в новый объект. B. После завершения функции временный объект, используемый в функции, выходит за пределы области видимости и уничтожается.

Теперь давайте посмотрим, что делает конструктор копирования.

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

// Copy constructor
T::T(T &old) {
    copy_data(m_a, old.m_a);
    copy_data(m_b, old.m_b);
    copy_data(m_c, old.m_c);
}

// Move constructor
T::T(T &&old) noexcept {
    m_a = std::move(old.m_a);
    m_b = std::move(old.m_b);
    m_c = std::move(old.m_c);
}