gpt4 book ai didi

c++ - operator->返回的指针的有效性

转载 作者:可可西里 更新时间:2023-11-01 18:38:18 26 4
gpt4 key购买 nike

我正在实现一个二维数组容器(如 boost::multi_array<T,2> ,主要用于练习)。为了使用双索引符号( a[i][j] ),我引入了一个代理类 row_view (和 const_row_view 但我不关心这里的常量性)它保持指向行的开头和结尾的指针。

我还希望能够分别遍历行和一行中的元素:

matrix<double> m;
// fill m
for (row_view row : m) {
for (double& elem : row) {
// do something with elem
}
}

现在,matrix<T>::iterator类(用于遍历行)保持私有(private) row_view rv;在内部跟踪迭代器指向的行。自然地,iterator还实现了取消引用功能:

  • operator*() ,人们通常会想要返回一个引用。相反,这里正确的做法似乎是返回一个 row_view。按值(即返回私有(private) row_view 的拷贝)。这确保了当迭代器前进时,row_view仍然指向上一行。 (在某种程度上,row_view 就像一个引用)。
  • operator->() , 我不确定。我看到两个选项:

    1. 返回一个指向私有(private)的指针row_view迭代器的:

      row_view* operator->() const { return &rv; }
    2. 返回指向新 row_view 的指针(私有(private)拷贝的拷贝)。由于存储生命周期的原因,必须在堆上进行分配。为了确保清理,我将其包装在 unique_ptr 中:

      std::unique_ptr<row_view> operator->() const {
      return std::unique_ptr<row_view>(new row_view(rv));
      }

显然,2 更正确。如果迭代器在 之后 前进 operator->被称为row_view 1 中指向的内容将会更改。然而,我能想到的唯一方法是,如果 operator->被全名调用,返回的指针被绑定(bind):

matrix<double>::iterator it = m.begin();
row_view* row_ptr = it.operator->();
// row_ptr points to view to first row
++it;
// in version 1: row_ptr points to second row (unintended)
// in version 2: row_ptr still points to first row (intended)

但是,这不是您通常使用 operator-> 的方式.在这样的用例中,您可能会调用 operator*并保留对第一行的引用。通常,人们会立即使用指针调用 row_view 的成员函数。或访问成员,例如it->sum() .

我现在的问题是:鉴于 ->语法建议立即使用,是 operator-> 返回的指针的有效性被认为仅限于那种情况,或者安全实现是否会导致上述“滥用”?

显然,解决方案 2 的成本更高,因为它需要堆分配。这当然是非常不受欢迎的,因为取消引用是一项很常见的任务并且没有真正需要它:使用 operator*而是避免了这些问题,因为它返回了 row_view 的堆栈分配拷贝.

最佳答案

如您所知,operator->递归地应用于函数返回类型,直到遇到原始指针。唯一的异常(exception)是在您的代码示例中按名称调用它时。

您可以利用它来发挥自己的优势并返回自定义代理对象。为避免出现上一个代码片段中的情况,此对象需要满足几个要求:

  1. 它的类型名称应该是私有(private)的 matrix<>::iterator ,因此外部代码无法引用它。

  2. 它的构造/复制/赋值应该是私有(private)的。 matrix<>::iterator将通过成为 friend 而接触到那些人。

一个实现看起来有点像这样:

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->() 的尝试按名称而不丢弃返回值,将不会编译。

Live Example

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 范围之外创建代理类的对象,但仍然可以绑定(bind)对它的引用:

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

因此允许申请operator->()再次。

直接的解决方案是限定代理对象的运算符,并使其仅适用于右值。就像我的现场示例一样:

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

这将导致上面的两行再次发出错误,而迭代器的正确使用仍然有效。不幸的是,由于转换的可用性,这仍然不能保护 API 免受滥用,主要是:

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

这是对整个努力的致命打击。这是无法阻止的。

所以总而言之,没有针对 operator-> 的方向调用的保护。在迭代器对象上。至多,我们只能让 API 很难被错误使用,而正确使用仍然很容易。

如果创建row_view拷贝范围很广,这可能就足够了。但这是你要考虑的。

另一个需要考虑的问题是,代理可用于实现写时复制,我在此答案中未提及。但是该类可能与我的回答中的代理一样容易受到攻击,除非非常小心并使用相当保守的设计。

关于c++ - operator->返回的指针的有效性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44758501/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com