Реализация конструктора перемещения путем вызова оператора присваивания перемещения

[...] сможет ли компилятор оптимизировать дополнительные инициализации?

Почти во всех случаях: да.

Должен ли я всегда писать свои конструкторы перемещения, вызывая оператор присваивания перемещения?

Да, просто реализуйте его с помощью оператора присваивания перемещения, за исключением случаев, когда вы измерили, что это приводит к неоптимальной производительности.

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

А давайте посмотрим на какую-нибудь сборку! Это показывает точный код с веб-сайта Microsoft с обеими версиями конструктора перемещения: вручную и с помощью назначения перемещения. Вот вывод сборки для GCC с -O (у -O1 такой же вывод; вывод clang приводит к тому же выводу):

; ===== manual version =====           |   ; ===== via move-assig =====
MemoryBlock(MemoryBlock&&):            |   MemoryBlock(MemoryBlock&&):
    mov     QWORD PTR [rdi], 0         |       mov     QWORD PTR [rdi], 0
    mov     QWORD PTR [rdi+8], 0       |       mov     QWORD PTR [rdi+8], 0
                                       |       cmp     rdi, rsi
                                       |       je      .L1
    mov     rax, QWORD PTR [rsi+8]     |       mov     rax, QWORD PTR [rsi+8]
    mov     QWORD PTR [rdi+8], rax     |       mov     QWORD PTR [rdi+8], rax
    mov     rax, QWORD PTR [rsi]       |       mov     rax, QWORD PTR [rsi]
    mov     QWORD PTR [rdi], rax       |       mov     QWORD PTR [rdi], rax
    mov     QWORD PTR [rsi+8], 0       |       mov     QWORD PTR [rsi+8], 0
    mov     QWORD PTR [rsi], 0         |       mov     QWORD PTR [rsi], 0
                                       |   .L1:
    ret                                |       rep ret

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

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

Это часто повторяется, но важно: не делайте преждевременной микрооптимизации!

Не поймите меня неправильно, я также ненавижу программное обеспечение, которое тратит впустую много ресурсов из-за ленивых или небрежных разработчиков или управленческих решений. А энергосбережение — это не только батарейки, но и экологическая тема, которой я очень увлечен. Но преждевременная микрооптимизация не помогает в этом отношении! Конечно, держите в уме алгоритмическую сложность и удобство кэширования больших данных. Но прежде чем выполнять какую-либо конкретную оптимизацию, измерьте!

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

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

Если вы хотите уменьшить количество кода, который вы пишете, просто не пишите элементы перемещения. Ваш класс будет отлично копироваться в контексте перемещения.

Если вы хотите, чтобы ваш код был высокопроизводительным, адаптируйте конструктор перемещения и назначение перемещения так, чтобы они выполнялись как можно быстрее. Члены Good Move будут невероятно быстрыми, и вы должны оценивать их скорость, подсчитывая грузы, магазины и филиалы. Если вы можете написать что-нибудь с 4 загрузками/сохранениями вместо 8, сделайте это! Если вы можете написать что-то без ветвей вместо 1, сделайте это!

Когда вы (или ваш клиент) помещаете свой класс в std::vector, для вашего типа может быть сгенерировано много ходов. Даже если ваш ход молниеносный при 8 загрузках/сохранениях, если вы можете сделать его в два раза быстрее или даже на 50% быстрее всего с 4 или 6 загрузками/сохранениями, имхо, это время потрачено не зря.

Лично мне надоело видеть ожидающие курсоры, и я готов пожертвовать дополнительными 5 минутами на написание своего кода и знаю, что это максимально быстро.

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

Моя версия C++11 класса MemoryBlock.

#include <algorithm>
#include <vector>
// #include <stdio.h>

class MemoryBlock
{
 public:
  explicit MemoryBlock(size_t length)
    : length_(length),
      data_(new int[length])
  {
    // printf("allocating %zd\n", length);
  }

  ~MemoryBlock() noexcept
  {
    delete[] data_;
  }

  // copy constructor
  MemoryBlock(const MemoryBlock& rhs)
    : MemoryBlock(rhs.length_) // delegating to another ctor
  {
    std::copy(rhs.data_, rhs.data_ + length_, data_);
  }

  // move constructor
  MemoryBlock(MemoryBlock&& rhs) noexcept
    : length_(rhs.length_),
      data_(rhs.data_)
  {
    rhs.length_ = 0;
    rhs.data_ = nullptr;
  }

  // unifying assignment operator.
  // move assignment is not needed.
  MemoryBlock& operator=(MemoryBlock rhs) // yes, pass-by-value
  {
    swap(rhs);
    return *this;
  }

  size_t Length() const
  {
    return length_;
  }

  void swap(MemoryBlock& rhs)
  {
    std::swap(length_, rhs.length_);
    std::swap(data_, rhs.data_);
  }

 private:
  size_t length_;  // note, the prefix underscore is reserved.
  int*   data_;
};

int main()
{
   std::vector<MemoryBlock> v;
   // v.reserve(10);
   v.push_back(MemoryBlock(25));
   v.push_back(MemoryBlock(75));

   v.insert(v.begin() + 1, MemoryBlock(50));
}

С правильным компилятором C++11 MemoryBlock::MemoryBlock(size_t) следует вызывать только 3 раза в тестовой программе.

Я не думаю, что вы заметите существенную разницу в производительности. Я считаю хорошей практикой использовать оператор присваивания перемещения из конструктора перемещения.

Однако я бы предпочел использовать std::forward вместо std::move, потому что это более логично:

*this = std::forward<MemoryBlock>(other);

Это зависит от того, что делает ваш оператор присваивания перемещения. Если вы посмотрите на статью в статье, на которую вы ссылаетесь, вы увидите частично:

  // Free the existing resource.
  delete[] _data;

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

Я бы просто исключил инициализацию члена и написал бы:

MemoryBlock(MemoryBlock&& other)
{
   *this = std::move(other);
}

Это всегда будет работать, если только при назначении перемещения не возникнут исключения, а обычно это не так!

Преимущества этого стиля:

1. Вам не нужно беспокоиться о том, будет ли компилятор дважды инициализировать члены, потому что это может различаться в разных средах.
2. Вы пишете меньше кода.
3. Вам не нужно обновлять его, даже если вы добавите в класс дополнительных участников в будущем.
4. Компиляторы часто могут встроить назначение перемещения, поэтому накладные расходы конструктора копирования будут минимальными.

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