问题标签 [shared-ptr]

当使用pImpl 成语时，最好使用 aboost:shared_ptr而不是 a std::auto_ptr？我确定我曾经读过boost版本对异常更友好？

[编辑] 使用 std::auto_ptr<> 是否总是安全的，或者是否存在需要替代提升智能指针的情况？

如果我有一个需要使用 a 的函数，shared_ptr将它的引用传递给它会不会更有效（以避免复制shared_ptr对象）？可能的不良副作用是什么？我设想了两种可能的情况：

1) 在函数内部，由参数制作副本，如

2）在函数内部只使用参数，如

在这两种情况下，我都看不到传递boost::shared_ptr<foo>值而不是引用的充分理由。按值传递只会“暂时”增加由于复制而导致的引用计数，然后在退出函数范围时减少它。我忽略了什么吗？

只是为了澄清一下，在阅读了几个答案之后：我完全同意过早优化问题，并且我总是尝试首先分析热点然后工作。如果您知道我的意思，我的问题更多是从纯技术代码的角度来看的。

我们有一个 C++ 库，我们提供给几个不同的客户。最近，我们从在公共接口中使用原始指针切换到使用 boost::sharedptr。正如您可能猜到的那样，这提供了巨大的好处，因为现在客户不再需要担心谁需要删除什么以及何时删除。当我们进行转换时，我认为这是正确的做法，但让我感到困扰的是，我们必须在我们的公共界面中包含来自第三方库的东西——通常，如果可以的话，你会避免这种事情。我合理化了 boost 现在实际上是 C++ 语言的一部分，我们的用例要求客户端代码和库都保存指向对象的指针。然而最近我们的一位客户问我们是否可以切换到在界面中使用中性智能指针类，因为我们的库本质上是在强迫他们使用特定版本的 boost——我当然理解和欣赏这一点。所以现在我想知道最好的行动方案是什么。我已经考虑了一点，并想知道创建一个简单的智能指针类，它只包含一个真正的 boost 智能指针。但是随后客户可能会立即将其中一个塞入他们的 boost::sharedptr 风格中，然后我们将深入三个共享指针——这可能是一个问题，也可能不是。无论如何，我很想听听社区关于解决这个问题的最佳方法的一些意见。我已经考虑了一点，并想知道创建一个简单的智能指针类，它只包含一个真正的 boost 智能指针。但是随后客户可能会立即将其中一个塞入他们的 boost::sharedptr 风格中，然后我们将深入三个共享指针——这可能是一个问题，也可能不是。无论如何，我很想听听社区关于解决这个问题的最佳方法的一些意见。我已经考虑了一点，并想知道创建一个简单的智能指针类，它只包含一个真正的 boost 智能指针。但是随后客户可能会立即将其中一个塞入他们的 boost::sharedptr 风格中，然后我们将深入三个共享指针——这可能是一个问题，也可能不是。无论如何，我很想听听社区关于解决这个问题的最佳方法的一些意见。

编辑：我最初说的是所有权转移，但我应该指定API边界两边的代码都需要持有一个指向对象的指针。

我在我的代码中大量使用了 boost::scoped_ptr，它很棒，但我目前正在使用到处使用 shared_ptr 的软件，我想知道我是否遗漏了一些东西。

AFAIK shared_ptr 仅在不同的线程要访问相同的数据并且您不知道线程将要完成的顺序时才有用（shared_ptr 确保对象存在直到最后一个线程完成它）。

还有其他用例吗？

我知道在一个模块中添加新内容并在另一个模块中删除它通常会导致 VC++ 出现问题。不同运行时的问题。如果我没记错的话，将模块与静态链接的运行时和/或动态链接的版本控制不匹配混合起来都会搞砸。

但是，跨模块使用 VC++ 2008 的 std::tr1::shared_ptr 是否安全？

由于只有一个版本的运行时甚至知道什么是 shared_ptr，所以静态链接是我唯一的危险（现在......）。我以为我已经读过 boost 的 shared_ptr 版本可以像这样安全使用，但我使用的是 Redmond 的版本......

我试图避免在分配模块中对释放对象进行特殊调用。（或类本身中的“删除这个”之类的东西）。如果这一切看起来有点 hacky，我正在使用它进行单元测试。如果您曾经尝试过对现有 C++ 代码进行单元测试，那么您就会明白有时您需要发挥多大的创造力。我的内存由 EXE 分配，但最终将在 DLL 中释放（如果引用计数按我认为的方式工作）。

我正在用 C++ 实现二叉树。传统上，我有一个指向左的指针和一个指向右的指针，但手动内存管理通常以泪水告终。这让我想到了我的问题......

数据结构是否适合使用 shared_ptr？

在使用智能指针的 C++ 项目中，例如boost::shared_ptr，关于使用“ this”的良好设计理念是什么？

考虑一下：

• 存储包含在任何智能指针中以供以后使用的原始指针是很危险的。您已经放弃了对对象删除的控制，并相信智能指针会在正确的时间执行此操作。

• 非静态类成员本质上使用this指针。这是一个原始指针，无法更改。

如果我曾经存储this在另一个变量中或将其传递给另一个函数，该函数可能会存储它以供以后使用，或者将其绑定到回调中，那么当任何人决定创建指向我的类的共享指针时，我就会创建错误。

鉴于此，我什么时候适合显式使用this指针？ 是否有可以防止与此相关的错误的设计范例？

在过去的两年里，我一直在我的项目中广泛使用智能指针（确切地说是 boost::shared_ptr）。我理解并欣赏他们的好处，而且我通常非常喜欢他们。但是我使用它们的次数越多，我就越想念 C++ 在内存管理和 RAII 方面的确定性行为，而我在编程语言中似乎喜欢这种行为。智能指针简化了内存管理过程并提供了自动垃圾收集等功能，但问题在于，通常使用自动垃圾收集，而智能指针具体会在（去）初始化的顺序上引入某种程度的不确定性。这种不确定性剥夺了程序员的控制权，正如我最近意识到的那样，设计和开发 API 的工作，

为了详细说明，我目前正在开发一个 API。此 API 的某些部分要求某些对象在其他对象之前初始化或在其他对象之后销毁。换句话说，（去）初始化的顺序有时很重要。举一个简单的例子，假设我们有一个名为 System 的类。系统提供了一些基本功能（在我们的示例中为日志记录），并通过智能指针保存了许多子系统。

正如您已经知道的那样，子系统仅在系统的上下文中才有意义。但是这种设计中的子系统很容易比其父系统寿命更长。

如果我们使用原始指针来保存子系统，那么当我们的系统出现故障时，我们就会破坏子系统，当然，pSomeSubsystem 将是一个悬空指针。

虽然保护客户端程序员免受自己的伤害不是 API 设计人员的工作，但让 API 易于正确使用和难以错误使用是一个好主意。所以我问你们。你怎么看？我应该如何缓解这个问题？你会如何设计这样一个系统？

在此先感谢，乔希

有人知道完全线程安全的shared_ptr实现吗？例如 boost 的实现shared_ptr对于目标（引用计数）是线程安全的，并且对于同时shared_ptr实例读取也是安全的，但对于写入或读/写则不是。

（参见Boost 文档，示例 3、4 和 5）。

shared_ptr是否存在对实例完全线程安全的 shared_ptr 实现？

奇怪的是 boost 文档说：

shared_ptr 对象提供与内置类型相同级别的线程安全。

但是，如果将普通指针（内置类型）与 进行比较smart_ptr，则同时写入普通指针是线程安全的，但同时写入 asmart_ptr则不是。

编辑：我的意思是 x86 架构上的无锁实现。

EDIT2：这种智能指针的一个示例用例是有许多工作线程使用它们当前的工作项更新全局 shared_ptr 和一个对工作项进行随机采样的监视器线程。shared-ptr 将拥有该工作项，直到另一个工作项指针被分配给它（从而破坏先前的工作项）。监视器将通过将工作项分配给它自己的 shared-ptr 来获得工作项的所有权（从而防止工作项被销毁）。可以通过 XCHG 和手动删除来完成，但如果 shared-ptr 可以做到这一点会很好。

另一个例子是全局 shared-ptr 拥有一个“处理器”，并由某个线程分配，并由某个其他线程使用。当“用户”线程看到处理器 shard-ptr 为 NULL 时，它使用一些替代逻辑来进行处理。如果它不是 NULL，它会通过将处理器分配给它自己的 shared-ptr 来防止处理器被破坏。

我对大多数理论都有扎实的理解，OOP但让我很困惑的一件事是虚拟析构函数。

我认为析构函数总是被调用，不管是什么，对于链中的每个对象。

你打算什么时候把它们变成虚拟的，为什么？