在库接口中提供对weak_ptr的访问是否明智？

Question

我编写了一个库，公开了对几种相关对象类型的引用。 所有这些对象的生命周期都由库通过 boost::shared_ptr 在内部管理。

库的用户还可以根据库的性质了解任何公开对象的生命周期。 因此它们可以存储指针或保留对这些对象的引用。 他们这样做并知道这些对象何时不再有效是合理的。

但我对强迫我的用户讲道理感到内疚。

让库向其对象公开 weak_ptr 是否可以接受？ 其他库是否这样做过？

我已经分析了该库在应用程序中的使用情况，并发现它对于任务至关重要，无法专门公开 weak_ptr。

让匹配的 API 函数暴露一个引用或一个weak_ptr，或者让任何对象能够向自身暴露一个weak_ptr，这会是更明智的做法吗？

Answer 1

如果库的用户已经可以直接访问 smart_ptr，那么他们就已经可以访问 weak_ptr，只需通过相应的 weak_ptr 即可> 的构造函数。 但如果 smart_ptr 都在库内部，那就是另一回事了。

在这种情况下，我建议除了您的库提供的任何其他访问之外，还让每个对象将 weak_ptr 传递给自身。 这为用户提供了最大的灵活性：如果他们需要 weak_ptr，他们可以立即访问它； 如果他们需要一个shared_ptr，他们可以轻松获得； 如果他们只需要访问对象本身，他们可以完全忽略智能指针。

当然，我不知道你们的图书馆是做什么的，也不知道它是如何使用或设计的。 这可能会改变我的建议。

Answer 2

提出复杂的机制来获取图书馆的对象只会导致人们不使用您的图书馆。 如果库的语义规定你需要让人使用weak_ptrs，那么用户就无法知道这些对象可能会在某个时候消失。 让界面尽可能多地表达有关库使用的信息，减少文档记录并使其更加易于使用。

你不能围绕糟糕/缺乏经验的用户进行设计。

Answer 3

如果您授予客户端访问 weak_ptr 的权限，他们只需锁定它们以创建 shared_ptr 并最终延迟对象的销毁。 这可能会导致您的库出现问题。

我建议将 weak_ptr 包装在其他类中，并为调用者提供一个 shared_ptr 。 这样他们就不能只调用 weak_ptr::lock()。 您似乎存在可能影响实现方式的性能限制，但 shared_ptr 可能是一个好方法，并将类保留在 weak_ptr 内部到你的图书馆。

这样，您还可以将这些实现细节保留在库接口之外，并且您可以在不更改接口的情况下更改实现方式。

Answer 4

我不认为暴露weak_ptrs有任何问题，特别是考虑到 TR1 有类似的智能指针 (PDF)。

TR1 主要由 Visual Studio 和 GCC 实现，但不是其他一些编译器实现的。 但是，当它在您关心的所有编译器中实现时，您可能需要重新设计 API 以公开这些智能指针。

Answer 5

如果您既想捕获对库的无效使用（在删除对象时尝试访问对象）又想拥有高性能 API（API 中没有weak_ptr 和shared_ptr），那么您可以考虑使用不同的API用于调试和非调试构建。

为了简单起见，我们假设您只公开一类对象； 将该类称为对象。 然后，您从用于访问内部对象的 API 返回的指针类型定义为：

#ifdef DEBUG
typedef ObjectPtrFacade ObjectPtr 
#else
typedef Object * ObjectPtr;
#endif

这里，外观是您编写的类。 它的工作原理大致如下：

class ObjectPtrFacade {
public:
    ObjectPtrFacade(Object *o) : wptr(o) { }
    // copy constructor and assignment here etc. (not written)
    Object * operator -> () const { return access(); }
    Object & operator * () const { return *access(); }
private:
    Object * access() { 
      assert(wptr.use_count() > 0);
      return (Object *)(wptr.lock());
    }
    weak_ptr<Object> wptr; 
}

通过这种方式，每当您构建调试版本时，都会使用一种特殊的智能指针，该指针在访问对象之前断言其 use_count() 大于零，即该对象仍然存在。 如果对象已被释放，您会得到一个失败的断言，这比空指针引用要好。

一般来说，如果您有“愚蠢”的API用户，那么使用weak_ptr并没有帮助，因为他们可以调用lock()，然后在weak_ptr返回空的shared_ptr后仍然进行空指针引用。 ..