使用智能指针作为“非拥有引用”的优缺点是什么？

Question

当一个对象需要引用另一个对象而不“拥有它”（即不对其生命周期负责）时，一种方法是简单地为此使用原始指针或原始引用，如下例所示：

class Node
{
    std::vector<Edge*> incidentEdges;
};

class Edge
{
    Node* startNode;
    Node* endNode;
};

class Graph
{
    std::vector<std::unique_ptr<Node*>> nodes;
    std::vector<std::unique_ptr<Edge*>> edges;
};

^{（请节省时间来评论是否存在更有效的图表数据结构，这是我的专业领域，而不是问题的重点。）}

Graph负责节点和边的生命周期，负责保证Node和Edge中的指针不悬空。但如果程序员没有这样做，就会有未定义行为的风险。

但是由于引用计数的开销成本，我们可以强烈地强制使用智能指针不会发生未定义的行为。相反，它会优雅地崩溃。它保证这发生在尽可能早的时间（避免损坏更多数据）并且不会被忽视。这是一种可能的实现方式：

^{（编辑：固定实现，Yakk 回答中的更多详细信息。非常感谢！）}

template <class T>
using owning_ptr = std::shared_ptr<T>;

template <class T>
class nonowning_ptr
{
    std::weak_ptr p_;

public:
    nonowning_ptr() : p_() {}
    nonowning_ptr(const nonowning_ptr & p) : p_(p.p_) {}
    nonowning_ptr(const owning_ptr<T> & p) : p_(p) {}

    // checked dereferencing
    owning_ptr<T> get() const
    { 
        if (auto sp = p_.lock())
        {
            return sp.get();
        }
        else
        {
            logUsefulInfo();
            saveRecoverableUserData();
            nicelyInformUserAboutError();
            abort(); // or throw exception
        }
    }

    T & operator*() const = delete; // cannot be made safe
    owning_ptr<T> operator->() const { return get(); }

    // [...] other methods forwarding weak_ptr functionality 
};

class Node
{
    std::vector<nonowning_ptr<Edge>> incidentEdges;
};

class Edge
{
    nonowning_ptr<Node> startNode;
    nonowning_ptr<Node> endNode;
};

class Graph
{
    std::vector<owning_ptr<Node>>> nodes;
    std::vector<owning_ptr<Edge>>> edges;
};

我的问题是：除了明显的性能与安全性权衡之外，每种方法的优缺点是什么？

我不是在问哪个是最好的，肯定没有最好的，这取决于用例。我在询问您可能知道而我不知道的每种方法的事实利弊，这将有助于做出设计决策（也许，在可读性方面？可维护性？可移植性？与第三方库玩得很好?preventing use-after-free exploits?)。

Answer 1

我的问题是：除了明显的性能与安全性权衡之外，每种方法的优缺点是什么？

忽略智能指针没有其他问题除了性能和安全性（性能是为什么我们不只是让 GC 安全地处理它），事实上，您的 nonowning_ptr 课程严重损坏。

您的get 函数返回一个裸指针。然而，您的代码中的任何地方都不能保证get 的任何用户都将获得一个有效的指针或NULL。

在您销毁由weak_ptr::lock 返回的shared_ptr 的那一刻，您删除了唯一保持该内存有效的东西。这意味着，如果有人出现并删除了该内存中的最后一个shared_ptr，而您拥有T*，那么您就完蛋了。

线程尤其打破了您对安全的幻想。

所以nonowning_ptr 最重要的“缺点”是它坏了；它并不比T* 更安全。

Answer 2

您的设计存在问题，如果另一个线程或执行路径（例如，函数调用的多个参数）修改了您的weak_ptr 底层的shared_ptr，则会在您之前进行生命周期检查使用它你会得到 UB。

为了减少这种情况，T * get() 应该是 std::shared_ptr<T> get()。 operator-> 也应该返回 std::shared_ptr<T>。虽然这看起来不切实际，但它实际上是有效的，因为 -> 在 C++ 中定义为自动递归的有趣方式。 （如果a 是指针类型，a-> 定义为(*a).，否则定义为(a.operator->())->。所以你的-> 返回一个shared_ptr，然后调用->，然后返回指针。这样可以确保您在 -> 上执行的指针的生命周期足够长。）

// checked dereferencing
std::shared_ptr<T> get() const
{ 
  if (auto sp = lock())
    return sp;
  fail();
}

void fail() { abort() } // or whatever
T & operator*() const = delete; // cannot be made safe
std::shared_ptr<T> operator->() const { return get(); } // works, magically

operator std::shared_ptr<T>() const { return lock(); }
std::shared_ptr<T> lock() const { return p_.lock(); }

现在p->foo(); 是（实际上）p->get()->foo()。 get() shared_ptr 返回值的生命周期比对 foo() 的调用长，所以一切都像房子一样安全。

T& operator() 调用中仍有一个漏洞，引用可能比其拥有的对象的寿命更长，但这至少修补了-> 漏洞。

为了安全起见，您可以选择完全禁止T& operator*()。

可以编写shared_reference<T> 来修补最后一个洞，但operator. 尚不可用。

同样，operator shared_ptr<T>() 会很好，.lock() 方法允许临时多行所有权。甚至可能是explicit operator bool()，但这会遇到共享指针和文件操作所具有的“检查，然后执行，但执行之前的检查可能无效”问题。