operator->返回的指针的有效性
Validity of pointer returned by operator->
我正在实现一个二维数组容器(如 boost::multi_array<T,2>
,主要用于练习)。为了使用双索引符号(a[i][j]
),我引入了一个代理 class 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
class(用于遍历行)在内部保留私有 row_view rv;
以跟踪迭代器指向的行。当然,iterator
也实现了解引用函数:
- 对于
operator*()
,人们通常会想要return一个参考。相反,这里正确的做法似乎是 return 按值 row_view
(即 return 私有 row_view
的副本)。这确保了当迭代器前进时,row_view
仍然指向上一行。 (在某种程度上,row_view
就像引用一样)。
对于 operator->()
,我不太确定。我看到两个选项:
Return指向迭代器的私有row_view
的指针:
row_view* operator->() const { return &rv; }
Return 指向新 row_view
的指针(私有的副本)。由于存储生命周期的原因,必须在堆上进行分配。为了确保清理,我将其包装在 unique_ptr
:
std::unique_ptr<row_view> operator->() const {
return std::unique_ptr<row_view>(new row_view(rv));
}
显然,2 更正确。如果迭代器前进after operator->
被调用,1中指向的row_view
会发生变化。但是,我能想到的唯一方法是,如果 operator->
是通过其全名调用的,并且绑定了 returned 指针:
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->
编辑的指针 return 的有效性是否被认为仅限于这种情况,或者 safe 实现会解释上述 "abuse"?
显然,解决方案 2 更昂贵,因为它需要堆分配。这当然是非常不受欢迎的,因为取消引用是一项非常常见的任务并且没有真正需要它:使用 operator*
代替可以避免这些问题,因为它 return 是 [= 的堆栈分配副本16=].
如您所知,operator->
递归地应用于函数 return 类型,直到遇到原始指针。唯一的例外是在您的代码示例中按名称调用它时。
您可以利用它来发挥自己的优势,return 自定义代理对象。为避免出现上一个代码片段中的情况,此对象需要满足几个要求:
它的类型名应该是 matrix<>::iterator
私有的,所以外部代码不能引用它。
它的 construction/copy/assignment 应该是私有的。 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->
return 命名对象的实现,以避免由于 C++17 中保证复制省略而导致的任何漏洞。使用内联运算符 (it->mem
) 的代码将像以前一样工作。但是,任何尝试通过名称调用 operator->()
而不丢弃 return 值,都不会编译。
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
范围之外创建代理 class 的对象,但仍然可以绑定对它的引用:
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
个副本的创建范围很广,这可能就足够了。但这是给你考虑的。
另一点需要考虑的是,我在这个答案中没有提到,代理可以用来实现写时复制。但是 class 可能和我回答中的代理一样容易受到攻击,除非非常小心并使用相当保守的设计。
我正在实现一个二维数组容器(如 boost::multi_array<T,2>
,主要用于练习)。为了使用双索引符号(a[i][j]
),我引入了一个代理 class 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
class(用于遍历行)在内部保留私有 row_view rv;
以跟踪迭代器指向的行。当然,iterator
也实现了解引用函数:
- 对于
operator*()
,人们通常会想要return一个参考。相反,这里正确的做法似乎是 return 按值row_view
(即 return 私有row_view
的副本)。这确保了当迭代器前进时,row_view
仍然指向上一行。 (在某种程度上,row_view
就像引用一样)。 对于
operator->()
,我不太确定。我看到两个选项:Return指向迭代器的私有
row_view
的指针:row_view* operator->() const { return &rv; }
Return 指向新
row_view
的指针(私有的副本)。由于存储生命周期的原因,必须在堆上进行分配。为了确保清理,我将其包装在unique_ptr
:std::unique_ptr<row_view> operator->() const { return std::unique_ptr<row_view>(new row_view(rv)); }
显然,2 更正确。如果迭代器前进after operator->
被调用,1中指向的row_view
会发生变化。但是,我能想到的唯一方法是,如果 operator->
是通过其全名调用的,并且绑定了 returned 指针:
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->
编辑的指针 return 的有效性是否被认为仅限于这种情况,或者 safe 实现会解释上述 "abuse"?
显然,解决方案 2 更昂贵,因为它需要堆分配。这当然是非常不受欢迎的,因为取消引用是一项非常常见的任务并且没有真正需要它:使用 operator*
代替可以避免这些问题,因为它 return 是 [= 的堆栈分配副本16=].
如您所知,operator->
递归地应用于函数 return 类型,直到遇到原始指针。唯一的例外是在您的代码示例中按名称调用它时。
您可以利用它来发挥自己的优势,return 自定义代理对象。为避免出现上一个代码片段中的情况,此对象需要满足几个要求:
它的类型名应该是
matrix<>::iterator
私有的,所以外部代码不能引用它。它的 construction/copy/assignment 应该是私有的。
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->
return 命名对象的实现,以避免由于 C++17 中保证复制省略而导致的任何漏洞。使用内联运算符 (it->mem
) 的代码将像以前一样工作。但是,任何尝试通过名称调用 operator->()
而不丢弃 return 值,都不会编译。
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
范围之外创建代理 class 的对象,但仍然可以绑定对它的引用:
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
个副本的创建范围很广,这可能就足够了。但这是给你考虑的。
另一点需要考虑的是,我在这个答案中没有提到,代理可以用来实现写时复制。但是 class 可能和我回答中的代理一样容易受到攻击,除非非常小心并使用相当保守的设计。