关于智能指针及其不可避免的不确定性的问题

Question

在过去的两年里，我在我的项目中广泛使用了智能指针（确切地说是 boost::shared_ptr）。 我理解并欣赏它们的好处，而且我通常非常喜欢它们。 但我使用它们越多，我就越怀念 C++ 在内存管理和 RAII 方面的确定性行为，而我似乎很喜欢这种编程语言。 智能指针简化了内存管理过程，并提供自动垃圾收集等功能，但问题是，一般情况下使用自动垃圾收集和智能指针会在初始化（取消）顺序上引入某种程度的不确定性。 这种不确定性剥夺了程序员的控制权，并且正如我最近意识到的那样，使得设计和开发 API 的工作（在开发时事先并不完全了解其用法）变得非常耗时，因为所有使用模式和极端情况都必须经过深思熟虑。

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

class System {
public:
    boost::shared_ptr< Subsystem > GetSubsystem( unsigned int index ) {
        assert( index < mSubsystems.size() );
        return mSubsystems[ index ];
    }

    void LogMessage( const std::string& message ) {
        std::cout << message << std::endl;
    }

private:
    typedef std::vector< boost::shared_ptr< Subsystem > > SubsystemList;
    SubsystemList mSubsystems;    
};

class Subsystem {
public:
    Subsystem( System* pParentSystem )
         : mpParentSystem( pParentSystem ) {
    }

    ~Subsystem() {
         pParentSubsystem->LogMessage( "Destroying..." );
         // Destroy this subsystem: deallocate memory, release resource, etc.             
    }

    /*
     Other stuff here
    */

private:
    System * pParentSystem; // raw pointer to avoid cycles - can also use weak_ptrs
};

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

int main() {
    {
        boost::shared_ptr< Subsystem > pSomeSubsystem;
        {
            boost::shared_ptr< System > pSystem( new System );
            pSomeSubsystem = pSystem->GetSubsystem( /* some index */ );

        } // Our System would go out of scope and be destroyed here, but the Subsystem that pSomeSubsystem points to will not be destroyed.

     } // pSomeSubsystem would go out of scope here but wait a second, how are we going to log messages in Subsystem's destructor?! Its parent System is destroyed after all. BOOM!

    return 0;
}

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

尽管保护客户端程序员免受自身侵害并不是 API 设计者的工作，但让 API 易于正确使用且难以错误使用是一个好主意。 所以我问你们。 你怎么认为？ 我应该如何缓解这个问题？ 你会如何设计这样一个系统？

提前致谢， 乔什

Answer 1

问题摘要

这个问题有两个相互竞争的问题。

1. 子系统的生命周期管理，允许在正确的时间删除它们。
2. 子系统的客户端需要知道他们正在使用的子系统是有效的。

处理 #1

System 拥有 Subsystem 并应在其自己的范围内管理其生命周期。 为此使用shared_ptr特别有用，因为它简化了销毁，但您不应该分发它们，因为这样您就失去了在释放它们时所寻求的确定性。

处理#2

这是需要解决的更有趣的问题。 更详细地描述问题，您需要客户端接收一个行为类似于子系统的对象，而该子系统（及其父系统）存在，但在子系统被销毁后表现正常。

通过组合代理模式可以轻松解决这个问题状态模式 和 空对象模式。 虽然这似乎是一个有点复杂的解决方案，“只有在复杂性的另一面才能拥有简单性”。 作为库/API 开发人员，我们必须付出更多努力来使我们的系统变得健壮。 此外，我们希望我们的系统能够像用户期望的那样直观地运行，并在他们试图滥用它们时优雅地衰退。 这个问题有很多解决方案，但是，这个解决方案应该让您到达所有重要的一点，正如您和 Scott Meyers 说，“正确使用很容易，错误使用很难。”

现在，我假设实际上，System 处理 Subsystem 的一些基类，您可以从中派生出各种不同的 Subsystem，我在下面介绍了它。 SubsystemBase。下面需要引入一个Proxy对象，SubsystemProxy，它实现了SubsystemBase的接口。 通过将请求转发到它所代理的对象（从这个意义上说，它非常像 装饰器模式。）每个子系统创建这些对象之一，并通过shared_ptr保存该对象，并在通过 GetProxy() 请求时返回，调用 GetSubsystem() 时由父 System 对象调用。

当System超出范围时，它的每个Subsystem对象都会被破坏。 在它们的析构函数中，它们调用 mProxy->Nullify()，这会导致它们的 Proxy 对象更改它们的 State 。 他们通过更改为指向空对象来实现此目的，该对象实现SubsystemBase接口，但不执行任何操作。

此处使用状态模式允许客户端应用程序完全不知道特定子系统是否存在。 此外，它不需要检查指针或保留应该被销毁的实例。

代理模式允许客户端依赖于一个轻量级对象，该对象完全封装了 API 内部工作的细节，并维护一个恒定、统一的接口。

空对象模式允许代理在原始子系统完成后运行已删除。

示例代码

我在这里放置了一个粗略的伪代码质量示例，但我对此并不满意。 我将其重写为我上面描述的精确的编译（我使用 g++）示例。 为了让它工作，我必须引入一些其他类，但它们的用途应该从它们的名称中清楚地看出。 我为 NullSubsystem 使用了单例模式 code> 类，因为您不需要多个类，这是有道理的。 ProxyableSubsystemBase 将代理行为从Subsystem 中完全抽象出来，使其能够忽略此行为。 以下是类的 UML 图：

示例代码：

#include <iostream>
#include <string>
#include <vector>

#include <boost/shared_ptr.hpp>


// Forward Declarations to allow friending
class System;
class ProxyableSubsystemBase;

// Base defining the interface for Subsystems
class SubsystemBase
{
  public:
    // pure virtual functions
    virtual void DoSomething(void) = 0;
    virtual int GetSize(void) = 0;

    virtual ~SubsystemBase() {} // virtual destructor for base class
};


// Null Object Pattern: an object which implements the interface to do nothing.
class NullSubsystem : public SubsystemBase
{
  public:
    // implements pure virtual functions from SubsystemBase to do nothing.
    void DoSomething(void) { }
    int GetSize(void) { return -1; }

    // Singleton Pattern: We only ever need one NullSubsystem, so we'll enforce that
    static NullSubsystem *instance()
    {
      static NullSubsystem singletonInstance;
      return &singletonInstance;
    }

  private:
    NullSubsystem() {}  // private constructor to inforce Singleton Pattern
};


// Proxy Pattern: An object that takes the place of another to provide better
//   control over the uses of that object
class SubsystemProxy : public SubsystemBase
{
  friend class ProxyableSubsystemBase;

  public:
    SubsystemProxy(SubsystemBase *ProxiedSubsystem)
      : mProxied(ProxiedSubsystem)
      {
      }

    // implements pure virtual functions from SubsystemBase to forward to mProxied
    void DoSomething(void) { mProxied->DoSomething(); }
    int  GetSize(void) { return mProxied->GetSize(); }

  protected:
    // State Pattern: the initial state of the SubsystemProxy is to point to a
    //  valid SubsytemBase, which is passed into the constructor.  Calling Nullify()
    //  causes a change in the internal state to point to a NullSubsystem, which allows
    //  the proxy to still perform correctly, despite the Subsystem going out of scope.
    void Nullify()
    {
        mProxied=NullSubsystem::instance();
    }

  private:
      SubsystemBase *mProxied;
};


// A Base for real Subsystems to add the Proxying behavior
class ProxyableSubsystemBase : public SubsystemBase
{
  friend class System;  // Allow system to call our GetProxy() method.

  public:
    ProxyableSubsystemBase()
      : mProxy(new SubsystemProxy(this)) // create our proxy object
    {
    }
    ~ProxyableSubsystemBase()
    {
      mProxy->Nullify(); // inform our proxy object we are going away
    }

  protected:
    boost::shared_ptr<SubsystemProxy> GetProxy() { return mProxy; }

  private:
    boost::shared_ptr<SubsystemProxy> mProxy;
};


// the managing system
class System
{
  public:
    typedef boost::shared_ptr< SubsystemProxy > SubsystemHandle;
    typedef boost::shared_ptr< ProxyableSubsystemBase > SubsystemPtr;

    SubsystemHandle GetSubsystem( unsigned int index )
    {
        assert( index < mSubsystems.size() );
        return mSubsystems[ index ]->GetProxy();
    }

    void LogMessage( const std::string& message )
    {
        std::cout << "  <System>: " << message << std::endl;
    }

    int AddSubsystem( ProxyableSubsystemBase *pSubsystem )
    {
      LogMessage("Adding Subsystem:");
      mSubsystems.push_back(SubsystemPtr(pSubsystem));
      return mSubsystems.size()-1;
    }

    System()
    {
      LogMessage("System is constructing.");
    }

    ~System()
    {
      LogMessage("System is going out of scope.");
    }

  private:
    // have to hold base pointers
    typedef std::vector< boost::shared_ptr<ProxyableSubsystemBase> > SubsystemList;
    SubsystemList mSubsystems;
};

// the actual Subsystem
class Subsystem : public ProxyableSubsystemBase
{
  public:
    Subsystem( System* pParentSystem, const std::string ID )
      : mParentSystem( pParentSystem )
      , mID(ID)
    {
         mParentSystem->LogMessage( "Creating... "+mID );
    }

    ~Subsystem()
    {
         mParentSystem->LogMessage( "Destroying... "+mID );
    }

    // implements pure virtual functions from SubsystemBase
    void DoSomething(void) { mParentSystem->LogMessage( mID + " is DoingSomething (tm)."); }
    int GetSize(void) { return sizeof(Subsystem); }

  private:
    System * mParentSystem; // raw pointer to avoid cycles - can also use weak_ptrs
    std::string mID;
};



//////////////////////////////////////////////////////////////////
// Actual Use Example
int main(int argc, char* argv[])
{

  std::cout << "main(): Creating Handles H1 and H2 for Subsystems. " << std::endl;
  System::SubsystemHandle H1;
  System::SubsystemHandle H2;

  std::cout << "-------------------------------------------" << std::endl;
  {
    std::cout << "  main(): Begin scope for System." << std::endl;
    System mySystem;
    int FrankIndex = mySystem.AddSubsystem(new Subsystem(&mySystem, "Frank"));
    int ErnestIndex = mySystem.AddSubsystem(new Subsystem(&mySystem, "Ernest"));

    std::cout << "  main(): Assigning Subsystems to H1 and H2." << std::endl;
    H1=mySystem.GetSubsystem(FrankIndex);
    H2=mySystem.GetSubsystem(ErnestIndex);


    std::cout << "  main(): Doing something on H1 and H2." << std::endl;
    H1->DoSomething();
    H2->DoSomething();
    std::cout << "  main(): Leaving scope for System." << std::endl;
  }
  std::cout << "-------------------------------------------" << std::endl;
  std::cout << "main(): Doing something on H1 and H2. (outside System Scope.) " << std::endl;
  H1->DoSomething();
  H2->DoSomething();
  std::cout << "main(): No errors from using handles to out of scope Subsystems because of Proxy to Null Object." << std::endl;

  return 0;
}

代码输出：

main(): Creating Handles H1 and H2 for Subsystems.
-------------------------------------------
  main(): Begin scope for System.
  <System>: System is constructing.
  <System>: Creating... Frank
  <System>: Adding Subsystem:
  <System>: Creating... Ernest
  <System>: Adding Subsystem:
  main(): Assigning Subsystems to H1 and H2.
  main(): Doing something on H1 and H2.
  <System>: Frank is DoingSomething (tm).
  <System>: Ernest is DoingSomething (tm).
  main(): Leaving scope for System.
  <System>: System is going out of scope.
  <System>: Destroying... Frank
  <System>: Destroying... Ernest
-------------------------------------------
main(): Doing something on H1 and H2. (outside System Scope.)
main(): No errors from using handles to out of scope Subsystems because of Proxy to Null Object.

其他想法：

• 我在《游戏编程宝石》一书中读到的一篇有趣的文章讨论了如何使用 Null用于调试和开发的对象。 他们特别讨论了使用空图形模型和纹理，例如棋盘纹理，以使缺失的模型真正脱颖而出。 通过将 NullSubsystem 更改为 ReportingSubsystem 也可以应用同样的方法，该子系统将记录调用，并可能在访问时记录调用堆栈。 这将允许您或您的图书馆的客户根据超出范围的内容来追踪他们所在的位置，但不需要导致崩溃。

• 我在@Arkadiy 的评论中提到，他在System 和Subsystem 之间提出的循环依赖有点令人不快。 通过让 System 派生自 Subsystem 所依赖的接口（Robert C Martin 的 依赖倒置原则。 更好的方法是将子系统所需的功能与其父系统隔离，为其编写一个接口，然后在系统中保留该接口的实现者并将其传递给子系统，它将通过shared_ptr保存它。 例如，您可能有 LoggerInterface，您的 Subsystem 使用它来写入日志，然后您可以派生 CoutLogger 或 FileLogger< /code> ，并在 System 中保留一个此类实例。


  


Answer 2

通过正确使用weak_ptr 类可以做到这一点。 事实上，您已经非常接近找到一个好的解决方案了。 你是对的，你不能期望你“超越”​​你的客户端程序员，你也不应该期望他们总是遵循你的 API 的“规则”（我相信你已经知道了）。 因此，您真正能做的最好的事情就是控制损害。

我建议您对 GetSubsystem 的调用返回一个 weak_ptr 而不是 shared_ptr，这样客户端开发人员就可以测试指针的有效性，而不必总是这样做。声称引用它。

同样，将 pParentSystem 设为 boost::weak_ptr，以便它可以通过调用在内部检测其父 System 是否仍然存在pParentSystem 上的lock 并检查NULL（原始指针不会告诉您这一点）。

假设您更改 Subsystem 类以始终检查其对应的 System 对象是否存在，您可以确保如果客户端程序员尝试使用 Subsystem 对象超出了将导致错误（由您控制​​）的预期范围，而不是莫名其妙的异常（您必须相信客户端程序员能够捕获/正确处理）。

因此，在您的 main() 示例中，事情不会进展顺利！ 在 Subsystem 的 dtor 中处理这个问题的最优雅的方法是让它看起来像这样：

class Subsystem
{
...
  ~Subsystem() {
       boost::shared_ptr<System> my_system(pParentSystem.lock());

       if (NULL != my_system.get()) {  // only works if pParentSystem refers to a valid System object
         // now you are guaranteed this will work, since a reference is held to the System object
         my_system->LogMessage( "Destroying..." );
       }
       // Destroy this subsystem: deallocate memory, release resource, etc.             

       // when my_system goes out of scope, this may cause the associated System object to be destroyed as well (if it holds the last reference)
  }
...
};

我希望这有帮助！

Answer 3

在这里，系统显然拥有子系统，我认为共享所有权没有任何意义。 我只是返回一个原始指针。 如果子系统的寿命比其系统的寿命长，那么它本身就是一个错误。

Answer 4

你在第一段的一开始就说对了。
您基于 RAII 的设计（如我的设计和大多数编写良好的 C++ 代码）要求您的对象由独占所有权指针持有。 在 Boost 中，这将是scoped_ptr。

那么为什么不使用scoped_ptr呢？ 这肯定是因为您希望利用weak_ptr的好处来防止悬空引用，但您只能将weak_ptr指向shared_ptr。 因此，当您真正想要的是单一所有权时，您采用了通常的做法，即方便地声明shared_ptr。 这是一个错误的声明，正如您所说，它会损害以正确的顺序调用析构函数。 当然，如果您从不共享所有权，您将侥幸逃脱 - 但您必须不断检查所有代码以确保它从未被共享。

更糟糕的是 boost::weak_ptr 使用起来不方便（它没有 -> 运算符），因此程序员通过错误地将被动观察引用声明为 share_ptr 来避免这种不便。 这当然共享所有权，如果您忘记将shared_ptr清空，那么您的对象将不会被销毁，也不会在您想要的时候调用它的析构函数。

简而言之，您已经被 boost 库欺骗了 - 它没有接受良好的 C++ 编程实践，并迫使程序员做出错误的声明，以便尝试从中获得一些好处。 它仅适用于编写真正想要共享所有权并且对严格控制内存或以正确顺序调用析构函数不感兴趣的粘合代码脚本。

我也曾走过和你一样的道路。 C++ 中迫切需要防止悬空指针，但 boost 库没有提供可接受的解决方案。 我必须解决这个问题 - 我的软件部门希望保证 C++ 的安全。 所以我自己做了 - 这是相当多的工作，可以在以下位置找到：

http ://www.codeproject.com/KB/cpp/XONOR.aspx

对于单线程工作来说它完全足够了，我即将更新它以支持跨线程共享的指针。 其主要特点是支持专有对象的智能（自归零）被动观察者。

不幸的是，程序员已经被垃圾收集和“一刀切”的智能指针解决方案所诱惑，并且在很大程度上甚至没有考虑所有权和被动观察者 - 结果他们甚至不知道他们正在做的事情是错误的并且不知道不要抱怨。 针对 Boost 的异端几乎闻所未闻！

向您建议的解决方案非常复杂，而且没有任何帮助。 它们是由于文化上不愿意承认对象指针具有必须正确声明的独特角色以及盲目相信 Boost 必须是解决方案而导致的荒谬例子。

Answer 5

我不认为让 System::GetSubsystem 返回指向子系统的原始指针（而不是智能指针）有问题。 由于客户端不负责构造对象，因此不存在客户端负责清理的隐式契约。 由于它是内部引用，因此可以合理地假设子系统对象的生命周期依赖于系统对象的生命周期。 然后，您应该通过文件说明这一隐含合同。

关键是，您没有重新分配或共享所有权 - 那么为什么要使用智能指针呢？

Answer 6

这里真正的问题是你的设计。 没有很好的解决方案，因为该模型没有反映良好的设计原则。 这是我使用的一个方便的经验法则：

• 如果一个对象包含其他对象的集合，并且可以从该集合返回任何任意对象，那么从您的设计中删除该对象。

我意识到你的例子是人为的，但它是我在工作中经常看到的一种反模式。 问问自己，加上 std::vectorSystem 的值是什么？ shared_ptr<子系统> > 不是吗？ API 的用户需要了解 SubSystem 的接口（因为您返回了它们），因此为它们编写持有者只会增加复杂性。 至少人们知道 std::vector 的接口，迫使他们记住 at() 上面的 GetSubsystem() 或 operator[ ] 只是意思。

你的问题是关于管理对象的生命周期，但是一旦你开始分发对象，你要么会因为允许其他人保持它们的活动而失去对生命周期的控制（shared_ptr），或者如果在它们被使用后使用它们，则会面临崩溃的风险。消失了（原始指针）。 在多线程应用程序中，情况更糟 - 谁锁定了您分发给不同线程的对象？ 当以这种方式使用时，增强共享指针和弱指针会导致复杂性陷阱，特别是因为它们的线程安全性足以让没有经验的开发人员陷入困境。

如果您要创建一个持有者，它需要向您的用户隐藏复杂性，并减轻他们可以自己管理的负担。 例如，一个接口由以下部分组成：a) 向子系统发送命令（例如 URI - /system/subsystem/command?param=value）和 b) 迭代子系统和子系统命令（通过类似 stl 的迭代器）以及可能的 c)注册子系统将允许您向用户隐藏几乎所有的实现细节，并在内部强制执行生命周期/排序/锁定要求。

在任何情况下，可迭代/可枚举的 API 都比公开对象更可取 - 命令/注册可以轻松序列化以生成测试用例或配置文件，并且可以交互式地显示它们（例如，在树形控件中，带有由查询组成的对话框）可用的操作/参数）。 您还可以保护您的 API 用户免受您可能需要对子系统类进行的内部更改的影响。

我会警告您不要遵循亚伦回答中的建议。 为如此简单的问题设计一个解决方案，需要 5 种不同的设计模式来实现，这只意味着解决了错误的问题。 我也厌倦了任何人在设计方面引用迈尔斯先生的话，因为他自己承认：

“我已经 20 多年没有编写过生产软件了，而且我从来没有用 C++ 编写过生产软件。不，从来没有。此外，我什至从未尝试过用 C++ 编写生产软件，所以我不仅不是真正的 C++ 开发人员，而且我什至不是一个想成为 C++ 开发者的人，稍微平衡一下这一点的是我在研究生期间确实用 C++ 编写了研究软件。学年（1985-1993），但即便如此，对于单个开发人员来说，这些内容也很小（几千行），很快就会被抛弃。自从十几年前开始担任顾问以来，我的 C++ 编程已经发生了变化。仅限于玩具“让我们看看它是如何工作的”（或者，有时，“让我们看看这会破坏多少个编译器”）程序，通常是适合单个文件的程序”。

并不是说他的书不值得一读，但他没有权力谈论设计或复杂性。

Answer 7

在您的示例中，如果系统持有 vector 而不是 vector 会更好。 >。 它既简单又消除您的担忧。 GetSubsystem 将返回一个引用。

Answer 8

堆栈对象将以与实例化相反的顺序释放，因此除非使用 API 的开发人员尝试管理智能指针，否则通常不会成为问题。 有些事情你无法阻止，你能做的最好的事情就是在运行时提供警告，最好只进行调试。

你的例子对我来说看起来非常像COM，你对使用shared_ptr返回的子系统进行了引用计数，但是你在系统对象本身上缺少它。

如果每个子系统对象在创建时对系统对象执行 addref 并在销毁时释放，则如果系统对象提前销毁时引用计数不正确，则至少可以显示异常。

使用weak_ptr还可以让你提供一条消息，而不是在以错误的顺序释放东西时爆炸。

Answer 9

你的问题的本质是循环引用：系统引用子系统，而子系统又引用系统。 这种数据结构无法通过引用计数轻松处理 - 它需要适当的垃圾收集。 您试图通过对边缘之一使用原始指针来打破循环 - 这只会产生更多的复杂性。

至少已经提出了两个好的解决方案，因此我不会尝试超越以前的海报。 我只能指出，在@Aaron 的解决方案中，您可以拥有系统代理而不是子系统代理 - 取决于更复杂的内容和有意义的内容。