ПочемуObserver_ptr не обнуляется после хода?

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

Рассмотреть возможность:

template<typename Mutex>
class unique_lock
{
  Mutex* pm;

public:
  unique_lock() : pm() { }

  unique_lock(Mutex& m) : pm(&m) { }

  ~unique_lock() { if (pm) pm->unlock(); }

  unique_lock(unique_lock&& ul) : pm(ul.pm) { ul.pm = nullptr; }

  unique_lock& operator=(unique_lock&& ul)
  {
    unique_lock(std::move(ul)).swap(*this);
    return *this;
  }

  void swap(unique_lock& ul) { std::swap(pm, ul.pm); }
};

С «глупым» интеллектуальным указателем, который имеет значение null-on-default-construction и null-after-move, вы можете по умолчанию использовать три специальные функции-члены, поэтому он становится:

template<typename Mutex>
class unique_lock
{
  tidy_ptr<Mutex> pm;

public:
  unique_lock() = default;                            // 1

  unique_lock(Mutex& m) : pm(&m) { }

  ~unique_lock() { if (pm) pm->unlock(); }

  unique_lock(unique_lock&& ul) = default;            // 2

  unique_lock& operator=(unique_lock&& ul) = default; // 3

  void swap(unique_lock& ul) { std::swap(pm, ul.pm); }
};

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

Но observer_ptr — это только конструкция null-on-default, поэтому, если она стандартизирована, она будет полезна для объявления функции, принимающей указатель, не являющийся владельцем, но она не будет полезна для классов, подобных приведенному выше, поэтому я Мне все еще нужен другой тип немого указателя, не являющийся владельцем. Наличие двух типов тупых умных указателей, не являющихся владельцами, кажется чуть ли не хуже, чем их отсутствие!

Таким образом, конструкторы перемещения предназначены для удешевления конструкторов копирования в определенных случаях.

Давайте напишем, какими должны быть эти конструкторы и деструкторы: (Это небольшое упрощение, но для данного примера это нормально).

observer_ptr() {
    this->ptr == nullptr;
}

observer_ptr(T *obj) {
    this->ptr = obj;
}

observer_ptr(observer_ptr<T> const & obj) {
    this->ptr = obj.ptr;
}

~observer_ptr() {
}

Вы предполагаете, что класс предоставляет конструктор перемещения, который выглядит так:

observer_ptr(observer_ptr<T> && obj) {
    this->ptr = obj.ptr;
    obj.ptr = null;
}

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

А как насчет std::vector?

std::vector при копировании фактически копирует массив, который он поддерживает. Итак, конструктор копирования std::vector выглядит примерно так:

vector(vector<T> const & obj) {
    for (auto const & elem : obj)
        this->push_back(elem);
}

Конструктор перемещения для std::vector может оптимизировать это. Это возможно, потому что эта память может быть украдена у obj. В std::vector это действительно полезно сделать.

vector(vector<T> && obj) {
    this->data_ptr = obj.data_ptr;
    obj.data_ptr = nullptr;
    obj.size = 0;
}

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

Однако существует потенциально гораздо более серьезная проблема с производительностью: по умолчанию функции перемещения позволяют observer_ptr быть легко копируется. Тривиальная копируемость позволяет копировать объект с помощью std::memcpy. Если бы observer_ptr не было тривиально копируемым, то не было бы и никаких классов с членом данных observer_ptr, что приводило бы к снижению производительности, которое ниспадало бы каскадом вниз по иерархии композиционных классов.

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