始终使用智能指针是一个好习惯吗？

Question

我发现智能指针比原始指针舒服得多。那么始终使用智能指针是个好主意吗？ （请注意，我来自 Java 背景，因此不太喜欢显式内存管理的想法。因此，除非智能指针存在一些严重的性能问题，否则我想坚持使用它们。）

注意：虽然我来了有Java背景，我非常了解智能指针的实现和RAII的概念。因此，在发布答案时，您可以认为我的这些知识是理所当然的。我几乎在所有地方都使用静态分配，并且仅在必要时才使用指针。我的问题只是：我可以始终使用智能指针代替原始指针吗？？？

Answer 1

鉴于多次编辑，我的印象是全面的总结会很有用。

1.什么时候不应该

有两种情况不应该使用智能指针。

第一种情况是完全相同的，实际上您不应该使用 C++ 类。 IE：如果不向客户端提供源代码，则为 DLL 边界。说个轶事吧。

第二种情况更常见：聪明的经理意味着所有权。您可以使用指针来指向现有资源，而不管理它们的生命周期，例如：

void notowner(const std::string& name)
{
  Class* pointer(0);
  if (name == "cat")
    pointer = getCat();
  else if (name == "dog")
    pointer = getDog();

  if (pointer) doSomething(*pointer);
}

本示例受到限制。但指针在语义上与引用不同，因为它可能指向无效位置（空指针）。在这种情况下，最好不要使用智能指针来代替它，因为您不想管理对象的生命周期。

2.智能管理器

除非您正在编写智能管理器类，否则如果您使用关键字 delete 您做错了什么。

这是一个有争议的观点，但在审查了这么多有缺陷的代码示例之后，我不再冒险了。因此，如果您编写new，您需要一个智能管理器来管理新分配的内存。而你现在就需要它。

这并不意味着您不是一个程序员！相反，重用已被证明有效的代码而不是一遍又一遍地重新发明轮子是一项关键技能。

现在，真正的困难开始了：哪个聪明的经理？

3.智能指针

市面上有各种各样的智能指针，它们具有不同的特性。

跳过您通常应该避免的 std::auto_ptr （它的复制语义被搞砸了）。

• scoped_ptr：无开销，无法复制或移动。
• unique_ptr：无开销，无法复制，可以移动。
• shared_ptr / weak_ptr：一些开销（引用计数），可以复制。

通常，尝试使用 scoped_ptr 或 unique_ptr。如果您需要多个所有者，请尝试更改设计。如果您无法更改设计并且确实需要多个所有者，请使用 shared_ptr，但要注意应该在中间某处使用 weak_ptr 来打破引用循环。

4.智能容器

许多智能指针并不是要复制的，因此它们在 STL 容器中的使用会受到一定程度的影响。

不要诉诸 shared_ptr 及其开销，而是使用 Boost 指针容器。它们模拟经典 STL 容器的接口，但存储它们自己的指针。

5.推出自己的

智能管理器 在某些情况下，您可能希望推出自己的智能管理器。请检查您是否错过了您之前使用的库中的某些功能。

在存在异常的情况下编写一个智能管理器是相当困难的。您通常不能假设内存可用（new 可能会失败）或复制构造函数具有不抛出保证。

在某种程度上，忽略 std::bad_alloc 异常并强制许多帮助器的复制构造函数不会失败可能是可以接受的......毕竟，那就是boost::shared_ptr 对其删除器 D 模板参数执行的操作。

但我不推荐它，尤其是对于初学者。这是一个棘手的问题，您现在不太可能注意到这些错误。

6.示例

// For the sake of short code, avoid in real code ;)
using namespace boost;

// Example classes
//   Yes, clone returns a raw pointer...
// it puts the burden on the caller as for how to wrap it
//   It is to obey the `Cloneable` concept as described in 
// the Boost Pointer Container library linked above
struct Cloneable
{
  virtual ~Cloneable() {}
  virtual Cloneable* clone() const = 0;
};

struct Derived: Cloneable
{
  virtual Derived* clone() const { new Derived(*this); }
};

void scoped()
{
  scoped_ptr<Cloneable> c(new Derived);
} // memory freed here

// illustration of the moved semantics
unique_ptr<Cloneable> unique()
{
  return unique_ptr<Cloneable>(new Derived);
}

void shared()
{
  shared_ptr<Cloneable> n1(new Derived);
  weak_ptr<Cloneable> w = n1;

  {
    shared_ptr<Cloneable> n2 = n1;          // copy

    n1.reset();

    assert(n1.get() == 0);
    assert(n2.get() != 0);
    assert(!w.expired() && w.get() != 0);
  } // n2 goes out of scope, the memory is released

  assert(w.expired()); // no object any longer
}

void container()
{
  ptr_vector<Cloneable> vec;
  vec.push_back(new Derived);
  vec.push_back(new Derived);

  vec.push_back(
    vec.front().clone()         // Interesting semantic, it is dereferenced!
  );
} // when vec goes out of scope, it clears up everything ;)

Answer 2

智能指针确实执行显式内存管理，如果您不了解它们是如何做到这一点的，那么在使用 C++ 编程时您就会遇到麻烦。请记住，内存并不是他们管理的唯一资源。

但要回答你的问题，你应该更喜欢智能指针作为解决方案的第一个近似值，但可能会在必要时准备放弃它们。如果可以避免，则永远不应该使用指针（或任何类型）或动态分配。例如：

string * s1 = new string( "foo" );      // bad
string s2( "bar" );    // good

编辑：要回答您的补充问题“我可以始终使用智能指针代替原始指针吗？？？那么，不，您不能。如果（例如）您需要实现您的自己版本的operator new，你必须让它返回一个指针，而不是一个智能指针。

Answer 3

通常，如果不需要指针（智能指针或其他指针），则不应使用它们。最好使局部变量、类成员、向量元素和类似项成为普通对象，而不是指向对象的指针。 （由于您来自 Java，因此您可能会尝试使用 new 分配所有内容，但不建议这样做。）

这种方法（“RAII") 可以让您在大多数时候不用担心指针。

当你必须使用指针时，这取决于具体情况以及为什么你需要指针，但通常可以使用智能指针。它可能不是总是（粗体）是最好的选择，但这取决于具体情况。

Answer 4

不使用智能指针的好时机是在 DLL 的接口边界处。您不知道是否会使用相同的编译器/库构建其他可执行文件。您的系统的 DLL 调用约定不会指定标准或 TR1 类的外观，包括智能指针。

在可执行文件或库中，如果您想表示指针对象的所有权，那么智能指针平均来说是最好的方法。因此，最好总是优先使用它们而不是原始的。您是否真的可以始终使用它们是另一回事。

举一个具体的例子，假设您正在编写一个通用图的表示，其中顶点由对象表示，边由对象之间的指针表示。通常的智能指针不会帮助你：图可以是循环的，并且没有特定的节点可以负责其他节点的内存管理，因此共享指针和弱指针是不够的。例如，您可以将所有内容放入向量中并使用索引而不是指针，或者将所有内容放入双端队列中并使用原始指针。如果需要，您可以使用 shared_ptr，但除了开销之外它不会增加任何内容。或者你可以寻找标记-清除GC。

更边缘的情况：我更喜欢看到函数通过指针或引用获取参数，并承诺不保留对其的指针或引用，而不是采用 shared_ptr 和让您想知道它们返回后是否保留引用，也许如果您再次修改引用对象，您会破坏某些东西，等等。不保留引用通常没有明确记录，这是不言而喻的。也许不应该，但确实如此。智能指针暗示了一些有关所有权的信息，而错误地暗示这一点可能会令人困惑。因此，如果您的函数采用 shared_ptr，请务必记录它是否可以保留引用。

Answer 5

在许多情况下，我相信它们绝对是正确的选择（更少混乱的清理代码，降低泄漏风险等）。然而，有一些非常轻微的额外费用。如果我正在编写一些必须尽可能快的代码（例如必须进行一些分配和释放的紧密循环），我可能不会使用智能指针来希望提高一点速度。但我怀疑在大多数情况下这不会产生任何可衡量的差异。

Answer 6

一般来说，不，你不能总是使用智能指针。例如，当您使用其他不使用智能指针的框架（如 Qt）时，您也必须使用原始指针。

Answer 7

如果您正在处理资源，则应始终使用 RAII 技术，在内存情况下意味着使用某种形式的智能指针（注意：智能指针，而不是 shared_ptr，选择最适合您的特定用例）。这是在出现异常时避免泄漏的唯一方法。

当资源管理不是通过指针处理时，仍然存在需要原始指针的情况。特别是，它们是获得可重置参考的唯一方法。考虑保留对生命周期无法显式处理的对象（成员属性、堆栈中的对象）的引用。但这是一个非常具体的情况，我只在实际代码中见过一次。在大多数情况下，使用 shared_ptr 是共享对象的更好方法。

Answer 8

我对智能指针的看法：当很难知道何时会发生释放时（比如在 try/catch 块内，或者在调用函数（甚至是构造函数！）的函数内，这可能会让您退出当前函数），这非常有用，或者为代码中到处都有 return 的函数添加更好的内存管理。或者将指针放入容器中。

然而，智能指针的成本可能是您不想在整个程序中付出的。如果内存管理很容易手动完成（“嗯，我知道当这个函数结束时我需要删除这三个指针，并且我知道这个函数将运行完成”），那么为什么要浪费计算机执行的周期它？

Answer 9

是的，但是我已经完成了几个没有使用智能指针或任何指针的项目。最好的做法是使用双端队列、列表、映射等容器。或者，如果可能的话，我会使用引用。我不是传递指针，而是传递引用或常量引用，删除/释放引用几乎总是不合逻辑的，所以我从来没有在那里遇到问题（通常我通过编写 { Class class; func(class ，参考2，参考3）；

Answer 10

这是。智能指针是老Cocoa（Touch）生态系统的基石之一。我相信它会不断影响新事物。