传递 const shared_ptr<T>& 而不是 shared_ptr<T> 作为参数

Question

我已经阅读了大量关于应用程序中涉及智能指针时的性能问题的讨论。常见的建议之一是将智能指针作为 const& 而不是副本传递，如下所示：

void doSomething(std::shared_ptr<T> o) {}

对

void doSomething(const std::shared_ptr<T> &o) {}

但是，第二个变体实际上不是破坏了共享指针的目的吗？我们实际上在这里共享共享指针，所以如果由于某些原因指针在调用代码中被释放（考虑可重入性或副作用），则 const 指针将变为无效。共享指针实际上应该防止的情况。我知道 const& 节省了一些时间，因为不涉及复制，也没有锁定来管理引用计数。但代价是代码的安全性降低了，对吧？

Answer 1

将shared_ptr 传递给const& 的优点是引用计数不必先增加再减少。因为这些操作必须是线程安全的，所以它们可能很昂贵。

您说得很对，您可以通过引用传递链，这会导致链的头部无效。这曾经发生在我的一个真实世界项目中，具有真实世界的后果。一个函数在容器中找到了shared_ptr，并将对它的引用传递到调用堆栈中。调用堆栈深处的一个函数从容器中删除了该对象，导致所有引用突然引用了一个不再存在的对象。

因此，当您通过引用传递某些内容时，调用者必须确保它在函数调用的整个生命周期内都存在。如果这是一个问题，请不要使用引用传递。

（我假设您有一个用例，其中有一些特定的原因通过 shared_ptr 而不是通过引用。最常见的原因是调用的函数可能需要延长对象的生命周期。 )

更新：为感兴趣的人提供有关该错误的更多详细信息：该程序具有共享的对象并实现了内部线程安全。它们被保存在容器中，延长它们的生命周期的函数很常见。

这种特殊类型的对象可以存在于两个容器中。一个是活动的，一个是不活动的。一些操作对活动对象起作用，一些对非活动对象起作用。当在非活动对象上接收到使其处于活动状态的命令而该对象的唯一 shared_ptr 由非活动对象的容器保存时，就会发生错误情况。

非活动对象位于其容器中。通过引用将容器中对shared_ptr 的引用传递给命令处理程序。通过一系列引用，这个shared_ptr 最终到达了意识到这是一个必须激活的非活动对象的代码。该对象已从非活动容器中移除（这破坏了非活动容器的 shared_ptr）并添加到活动容器中（这添加了对传递给“add”例程的 shared_ptr 的另一个引用）。

此时，存在的对象的唯一shared_ptr 可能是非活动容器中的那个。调用堆栈中的每个其他函数都只是对它的引用。当对象从非活动容器中移除时，对象可能会被销毁，并且所有这些引用都指向不再存在的 shared_ptr。

花了大约一个月的时间才解开这个问题。

Answer 2

首先，不要将shared_ptr 传递到调用链中，除非其中一个被调用函数可能会存储它的副本。传递对被引用对象的引用，或指向该对象的原始指针，或者可能是一个框，具体取决于它是否是可选的。

但是当您确实传递了shared_ptr 时，最好通过引用const 来传递它，因为复制shared_ptr 会产生额外的开销。复制必须更新共享引用计数，并且此更新必须是线程安全的。因此，可以（安全地）避免一些低效率。

关于

”价格降低了代码的安全性，对吧？

没有。代价是天真生成的机器代码的额外间接，但编译器管理它。因此，这一切都是为了避免编译器无法为您优化的微小但完全不必要的开销，除非它是超级智能的。

正如 David Schwarz 在他的回答中举例说明的那样，当您通过引用 const 传递 别名问题时，您调用的函数依次更改或调用更改原始对象的函数，是可能的。根据墨菲定律，它将发生在最不方便的时间，以最大的成本，以及最复杂的难以理解的代码。但无论参数是string 还是shared_ptr 或其他什么，都是如此。令人高兴的是，这是一个非常罕见的问题。但请记住，也用于传递 shared_ptr 实例。

Answer 3

首先两者之间存在语义上的区别： 按值传递共享指针表明您的函数将获得底层对象所有权的一部分。 除了强制此函数的用户使用 shared_ptr 之外，将 shared_ptr 作为 const 引用传递并不表示仅通过 const 引用（或原始指针）传递底层对象的任何意图。所以大部分都是垃圾。

只要它们在语义上不同，比较它们的性能影响是无关紧要的。

来自https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/

除非您愿意，否则不要将智能指针作为函数参数传递 使用或操作智能指针本身，例如共享或 转让所有权。

这一次我完全同意 Herb :)

另一句同样的引述，更直接地回答了这个问题

指南：仅使用非常量 shared_ptr& 参数来修改 shared_ptr。仅当您不确定是否会复制并共享所有权时，才使用 const shared_ptr& 作为参数；否则使用 * 代替（或者如果不可为空，则使用 &）

Answer 4

正如C++ - shared_ptr: horrible speed 中所指出的，复制shared_ptr 需要时间。构造涉及原子增量和销毁原子减量，原子更新（无论是增量还是减量）可能会阻止许多编译器优化（内存加载/存储不能跨操作迁移）并且在硬件级别涉及 CPU 缓存一致性协议以确保整个缓存行由进行修改的核心拥有（独占模式）。

所以，你是对的，std::shared_ptr<T> const& 可以用作对 std::shared_ptr<T> 的性能改进。

---

您也说对了，指针/引用在理论上存在由于一些别名而悬空的风险。

话虽如此，任何 C++ 程序中都存在潜在风险：任何一次使用指针或引用都是一种风险。我认为与T&、T const&、T*、...的总使用次数相比，std::shared_ptr<T> const& 的少数出现应该是水中的一滴水。

---

最后，我想指出传递shared_ptr<T> const& 是奇怪。以下情况比较常见：

• shared_ptr<T>：我需要一份shared_ptr
• T*/T const&/T&/T const&：我需要T的（可能为空）句柄

下一种情况不太常见：

• shared_ptr<T>&：我可以重新安装shared_ptr

但是通过shared_ptr<T> const&？合法用途非常罕见。

传递shared_ptr<T> const& 而你想要的只是对T 的引用是一种反模式：当用户可以通过另一种方式分配T 时，你会强制用户使用shared_ptr！大多数时候（99,99..%），您不应该关心T 是如何分配的。

您会传递shared_ptr<T> const& 的唯一情况是，如果您不确定是否需要副本，并且因为您已经分析了程序并表明这个原子增量/减量是您决定的瓶颈将副本的创建推迟到需要的情况下。

这是一种极端情况，任何使用shared_ptr<T> const& 的行为都应该受到最高程度的怀疑。

Answer 5

如果您的方法中不涉及所有权修改，则您的方法通过复制或通过 const 引用获取 shared_ptr 没有任何好处，它会污染 API 并可能产生开销（如果通过复制传递）

干净的方法是通过 const ref 或 ref 传递基础类型，具体取决于您的用例

void doSomething(const T& o) {}

auto s = std::make_shared<T>(...);
// ...
doSomething(*s);

方法调用过程中不能释放底层指针

Answer 6

如果目标函数是同步的并且仅在执行期间使用参数并且在返回时不再需要它，我认为传递const & 是完全合理的。在这里节省增加引用计数的成本是合理的——因为在这些有限的情况下你并不需要额外的安全——只要你了解其中的含义并确定代码是安全的。

这与函数需要保存参数（例如在类成员中）以供以后重新引用时相反。