【问题标题】:Can an expired weak_ptr be distinguished from an uninitialized one?可以将过期的weak_ptr 与未初始化的weak_ptr 区分开来吗?
【发布时间】:2015-01-10 21:14:57
【问题描述】:

例如:

std::weak_ptr<int> wp1(std::make_shared<int>());
std::weak_ptr<int> wp2;

assert(PointsToValidOrExpiredObject(wp1));
assert(!PointsToValidOrExpiredObject(wp2));

这样的功能可能吗?

用例:类的构造函数将std::weak_ptr&lt;Foo&gt; 作为依赖项。传递过期对象是可以的(可能在某些工作流程中发生),但传递 null 意味着程序员忘记了一些东西。作为构造函数参数验证的一部分,我想对此进行测试。

【问题讨论】:

  • expired()方法了吗?
  • @Borgleader。是的——不幸的是,这两种情况都返回 true。
  • 虽然似乎有一个答案,但一个不那么神奇的解决方案可能是将弱指针包装在一个只能用非空共享指针构造的类型中,并要求它而不是原始弱指针。

标签: c++ c++11 weak-ptr


【解决方案1】:

std::weak_ptr::owner_before可以区分为空和过期的弱指针。因此,您可以将PointsToValidOrExpiredObject 实现为:

template <typename T>
bool PointsToValidOrExpiredObject(const std::weak_ptr<T>& w) {
    return w.owner_before(std::weak_ptr<T>{}) ||
           std::weak_ptr<T>{}.owner_before(w);
}

Demo.

Regarding the original uncertainty I had about an expired weak_ptr still maintaining ownership:我现在确定一般库范围的线程安全要求要求过期的weak_ptr 继续拥有相同的所有权。否则,销毁线程 A 中最后一个剩余的 shared_ptr 将不得不明显地修改一个/一些/所有 weak_ptrs 的状态,这些 weak_ptrs 与所讨论的 shared_ptr 共享所有权。如果线程 B 正在同时检查这样一个 weak_ptr 的状态,那么您将遇到由库实现引入的数据竞争,这通常是被禁止的。

【讨论】:

  • 似乎确实如此。指针是等效的“如果它们共享所有权或都为空”,并且没有任何迹象表明弱指针在到期时变为空(并停止共享所有权)。
  • 太棒了!我不得不查阅owner_before 文档以了解这意味着什么以及它为什么起作用。对于处于相同情况的其他人:您可以将此函数想象为operator &lt;,在实践中,它比较地址。因此,如果 this owner_before 存在的主要原因是为了方便在地图中使用weak_ptr 作为键,但它在这里也很有用!
猜你喜欢
  • 2023-03-20
  • 2022-01-16
  • 1970-01-01
  • 2011-06-26
  • 1970-01-01
  • 1970-01-01
  • 2021-11-10
  • 1970-01-01
相关资源
最近更新 更多