c++ - 在公共(public)接口(interface)中使用共享指针

Question

我们有一个使用共享指针的非常标准的树 API，大致如下所示(为简洁起见省略了实现):

class node;
using node_ptr = std::shared_ptr<node>;

class node : public std::enable_shared_from_this<node> {
    std::weak_ptr<node> parent;
    std::vector<node_ptr> children;

public:
    virtual ~node() = default;

    virtual void do_something() = 0;

    void add_child(node_ptr new_child);

    void remove_child(node_ptr child);

    node_ptr get_parent();

    const std::vector<node_ptr>& get_children();
};

class derived_node : public node {
    derived_node() = default;

public:
    virtual void do_something() override;

    static node_ptr create(/* args... */);
};

// More derived node types...

这工作得很好，可以防止节点像您想象的那样被泄露。但是，我已经阅读了关于 SO 的各种其他答案，在这样的公共(public) API 中使用 std::shared_ptr 被认为是不好的风格，应该避免。

显然这会冒险进入基于意见的领域，所以有几个具体问题可以避免这个问题被关闭 :-)

• 在像这样的接口(interface)中使用 shared_ptr 是否存在任何众所周知的陷阱，到目前为止我们已经幸运地避免了这些陷阱？

• 如果是这样，是否有一种常用的(我不愿说是“惯用的”)替代公式可以避免上述陷阱但仍允许用户进行简单的内存管理？

谢谢。

Answer 1

它的风格不错，它取决于您的目标和假设。

我在严格限制下完成的一些项目要求我们避免使用 shared_ptr，因为我们想管理自己的内存。因此，需要使用 shared_ptrs 的第 3 方库的使用已被淘汰。

您可能希望避免使用 shared_ptrs 的另一个原因是它有些自以为是。一些项目会围绕它包装所有东西，并假装它就像拥有 GC 语言(急!)。其他项目会更严格地对待 shared_ptr，并且仅在归结为具有共享所有权的实际事物时才使用 shared_ptr。

我使用过的大多数第 3 方 API(当然不是全部)都按照以下原则运行:如果分配了它，就会销毁它。只要您非常清楚资源的所有权，就不会造成太大问题。