Действительность указателя, возвращаемого оператором-›

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

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

1. Имя его типа должно быть приватным для matrix<>::iterator, чтобы внешний код не мог ссылаться на него.

2. Его построение/копирование/присвоение должно быть частным. matrix<>::iterator будет иметь к ним доступ, поскольку является другом.

Реализация будет выглядеть примерно так:

template <...>
class matrix<...>::iterator {
private:
  class row_proxy {
    row_view *rv_;
    friend class iterator;
    row_proxy(row_view *rv) : rv_(rv) {}
    row_proxy(row_proxy const&) = default;
    row_proxy& operator=(row_proxy const&) = default;
  public:
    row_view* operator->() { return rv_; }
  };
public:
  row_proxy operator->() {
    row_proxy ret(/*some row view*/);
    return ret;
  }
};

Реализация operator-> возвращает именованный объект, чтобы избежать лазеек из-за гарантированного удаления копии в C++17. Код, использующий встроенный оператор (it->mem), будет работать, как и раньше. Однако любая попытка вызвать operator->() по имени без отбрасывания возвращаемого значения не будет скомпилирована.

Живой пример

struct data {
    int a;
    int b;
} stat;

class iterator {
    private:
      class proxy {
        data *d_;
        friend class iterator;
        proxy(data *d) : d_(d) {}
        proxy(proxy const&) = default;
        proxy& operator=(proxy const&) = default;
      public:
        data* operator->() { return d_; }
      };
    public:
      proxy operator->() {
        proxy ret(&stat);
        return ret;
      }
};


int main()
{
  iterator i;
  i->a = 3;

  // All the following will not compile
  // iterator::proxy p = i.operator->();
  // auto p = i.operator->();
  // auto p{i.operator->()};
}

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

auto &&r = i.operator->();
auto *d  = r.operator->();

Это позволяет снова применить operator->().

Немедленное решение состоит в том, чтобы квалифицировать оператор прокси-объекта и сделать его применимым только к rvalue. Например, для моего живого примера:

data* operator->() && { return d_; }

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

auto &&r = i.operator->();
auto *d  = std::move(r).operator->();

Что является смертельным ударом для всего начинания. Этому не помешает.

Итак, в заключение, нет никакой защиты от вызова направления operator-> на объекте итератора. В лучшем случае мы можем только сделать API очень сложным для неправильного использования, в то время как правильное использование остается простым.

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

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