Защо 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-construction, така че ако е стандартизирано, ще бъде полезно за деклариране на функция, която да вземе непритежаващ указател, но няма да е полезно за класове като този по-горе, така че аз все още ще има нужда от друг непритежаващ тъп тип показалец. Да имаш два типа тъпи интелигентни показалци, които не притежават, изглежда почти по-лошо, отколкото да нямаш нито един!

И така, конструкторите за преместване са предназначени да направят конструкторите за копиране по-евтини в определени случаи.

Нека напишем какви очакваме да бъдат тези конструктори и деструктори: (Това е малко опростено, но е добре за този пример).

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

Освен незначителното въздействие върху производителността от нулирането на moved-from observer_ptr, което лесно се заобикаля (копиране вместо преместване), основната обосновка вероятно е да се имитира поведението на обикновените указатели възможно най-близо, следвайки принцип на най-малката изненада.

Има обаче потенциално много по-значим проблем с производителността: настройката по подразбиране на функциите за преместване позволява observer_ptr да бъде тривиално копируем. Тривиалната възможност за копиране позволява обект да бъде копиран с помощта на std::memcpy. Ако observer_ptr не можеше да се копира тривиално, нито класове с observer_ptr член на данните, което води до понижаване на производителността, което се спуска каскадно надолу по йерархията на композиционния клас.

Нямам представа какви подобрения на производителността могат да бъдат постигнати чрез използване на оптимизацията std::memcpy, но те вероятно са по-значими от гореспоменатия незначителен проблем с производителността.