为什么C ++库和框架从不使用智能指针？

我读过几篇文章，几乎不应该使用原始指针。相反，它们应始终包装在智能指针中，无论是作用域指针还是共享指针。

但是，我注意到Qt，wxWidgets之类的框架以及Boost之类的库从不返回也不期望有智能指针，就好像它们根本没有使用它们一样。相反，它们返回或期望原始指针。有什么理由吗？编写公共API时，我应该远离智能指针吗？为什么？

只是想知道为什么在许多大型项目似乎都避免使用智能指针的情况下建议使用智能指针。

除了许多库是在标准智能指针问世之前编写的，最大的原因可能是缺少标准的C ++应用程序二进制接口（ABI）。

如果您正在编写仅标头的库，则可以将智能指针和标准容器传递到您的内心所在。它们的源可在编译时提供给您的库，因此您仅依赖于其接口的稳定性，而不是其实现的稳定性。

但是由于缺乏标准的ABI，您通常无法跨模块边界安全地传递这些对象。GCC shared_ptr可能不同于MSVC shared_ptr，后者也可能不同于Intel shared_ptr。即使使用相同的编译器，也不能保证这些类在版本之间是二进制兼容的。

底线是，如果要分发库的预构建版本，则需要依赖的标准ABI。C没有，但是编译器供应商对于给定平台的C库之间的互操作性非常好-实际上存在标准。

这种情况对于C ++而言并不理想。各个编译器可以处理它们自己的二进制文件之间的互操作，因此您可以选择为每个受支持的编译器（通常是GCC和MSVC）分发版本。但是鉴于此，大多数库仅导出C接口-这意味着原始指针。

但是，非库代码通常应优先使用智能指针而不是原始指针。

可能有很多原因。要列出其中一些：

1. 智能指针刚刚成为标准的一部分。直到那时他们才是其他图书馆的一部分
2. 它们的主要用途是避免内存泄漏。许多库没有自己的内存管理；通常，它们提供实用程序和API
3. 它们被实现为包装器，因为它们实际上是对象而不是指针。与原始指针相比，它具有额外的时间/空间成本；库的用户可能不希望有这样的开销

编辑：使用智能指针是完全开发人员的选择。这取决于各种因素。

1. 在性能至关重要的系统中，您可能不想使用会产生开销的智能指针

2. 需要向后兼容性的项目，您可能不想使用具有C ++ 11特定功能的智能指针

Edit2由于下面的段落，在24小时内有一连串的否决票。我无法理解为什么答案被低估，即使以下只是附加建议而不是答案。
但是，C ++总是可以帮助您打开选项。:)例如

template<typename T>
struct Pointer {
#ifdef <Cpp11>
  typedef std::unique_ptr<T> type;
#else
  typedef T* type;
#endif
};

并在您的代码中将其用作：

Pointer<int>::type p;

对于那些说智能指针和原始指针不同的人，我同意这一点。上面的代码只是一个想法，一个人可以编写可以与a互换的代码#define，这不是强制 ;

例如，T*必须显式删除，但智能指针不能删除。我们可以有一个模板Destroy()来处理。

template<typename T>
void Destroy (T* p)
{
  delete p;
}
template<typename T>
void Destroy (std::unique_ptr<T> p)
{
  // do nothing
}

并将其用作：

Destroy(p);

同样，对于原始指针，我们可以直接复制它；对于智能指针，我们可以使用特殊操作。

Pointer<X>::type p = new X;
Pointer<X>::type p2(Assign(p));

哪里Assign()是：

template<typename T>
T* Assign (T *p)
{
  return p;
}
template<typename T>
... Assign (SmartPointer<T> &p)
{
  // use move sematics or whateve appropriate
}

智能指针（C ++ 11之前的版本）存在两个问题：

• 非标准的，因此每个库都倾向于重塑自己的库（NIH语法和依赖关系问题）
• 潜在成本

在默认的智能指针，因为它是无成本，是unique_ptr。不幸的是，它需要C ++ 11 move语义，这种语义直到最近才出现。所有其他智能指针拥有成本（shared_ptr，intrusive_ptr）或有不太理想的语义（auto_ptr）。

随着C ++ 11的到来，带一个std::unique_ptr，人们会以为它终于结束了……我并不那么乐观。

只有少数主要编译器实现了大多数C ++ 11，并且仅在其最新版本中实现。我们可以预期QT和Boost等主要库愿意在一段时间内保持与C ++ 03的兼容性，这在某种程度上阻止了新的闪亮的智能指针的广泛采用。

您不应该远离智能指针，尤其是在必须传递对象的应用程序中，它们会发挥作用。

库倾向于只返回一个值或填充一个对象。它们通常没有很多地方需要使用的对象，因此它们不需要使用智能指针（至少不在其接口中，它们可以在内部使用）。

我可以举一个我们一直在研究的库为例，经过几个月的开发，我意识到我们只在少数几个类中使用了指针和智能指针（占所有类的3-5％）。

在大多数情况下，通过引用传递变量就足够了，只要有可能为null的对象，我们就使用智能指针，而当我们使用的库迫使我们使用时，则使用原始指针。

编辑（由于我的声誉，我无法评论）：通过引用传递变量非常灵活：如果您希望对象是只读的，则可以使用const引用（您仍然可以进行一些讨厌的强制转换以编写该对象），但您会获得最大程度的保护（智能指针也是如此）。但是我确实同意只返回对象会更好。

Qt毫无意义地重新发明了标准库的许多部分，试图成为Java。我相信它实际上确实有自己的智能指针，但总的来说，它几乎不是设计的顶峰。据我所知，wxWidgets是在编写可用的智能指针之前就设计的。

至于Boost，我完全希望它们在适当的地方使用智能指针。您可能需要更具体。

另外，不要忘记存在智能指针来强制所有权。如果API没有所有权语义，那么为什么要使用智能指针？

好问题。我不知道您所引用的具体文章，但我不时阅读类似的文章。我的怀疑是，此类文章的作者倾向于对C ++风格的编程怀有偏见。如果编写者仅在必要时使用C ++进行编程，然后尽快返回Java或类似的语言，那么他实际上并不会分享C ++的思维方式。

一个人怀疑某些或大多数相同的作者更喜欢垃圾收集内存管理器。我没有，但是我和他们的想法不同。

智能指针很棒，但是它们必须保留引用计数。保留参考计数会产生成本-通常是适度的成本，但是仍然会在运行时产生成本。通过使用裸指针来节省这些成本没有什么错，尤其是在指针由析构函数管理的情况下。

C ++的优点之一是它对嵌入式系统编程的支持。使用裸指针是其中的一部分。

更新： 评论者已正确观察到C ++的新功能unique_ptr（自TR1起可用）不计算引用。评论者对“智能指针”的定义也与我所想到的不同。他可能对定义是正确的。

进一步更新： 下面的注释线程将点亮。建议阅读所有内容。

还有其他类型的智能指针。您可能需要专门的智能指针来处理诸如网络复制之类的东西（用于检测是否已访问它并将任何修改发送到服务器等），保留更改历史记录，标记已被访问的事实，以便可以在何时进行调查。您将数据保存到磁盘等。不确定在指针中执行此操作是否是最佳解决方案，但在库中使用内置的智能指针类型可能会导致人们被锁定在其中并失去灵活性。

人们可以拥有智能指针之外的各种不同的内存管理要求和解决方案。我可能想自己管理内存，我可能正在为内存池中的东西分配空间，因此它是预先分配的，而不是在运行时分配的（对游戏有用）。我可能正在使用C ++的垃圾回收实现（C ++ 11使这成为可能，尽管尚不存在）。或者，也许我只是没有做任何足以使他们烦恼的高级事情，我可以知道我不会忘记未初始化的对象等等。也许我对不用指针就可以管理内存的能力充满信心。

与C集成也是另一个问题。

另一个问题是智能指针是STL的一部分。C ++设计为无需STL就可以使用。

这也取决于您在哪个领域工作。我以谋生为目的编写游戏引擎，我们避免像瘟疫一样避免加速，在游戏中，加速的开销是不可接受的。在我们的核心引擎中，我们最终编写了自己的stl版本（非常类似于ea stl）。

如果我要编写表单应用程序，则可以考虑使用智能指针。但是一旦内存管理成为第二天性，就无法对内存进行精细控制变得很烦人。