C++ 中的对象是否应该删除自身？

Question

过去 4 年我一直在使用 C#，因此我对 C++ 中当前的最佳实践和常见设计模式很感兴趣。 考虑以下部分示例：

class World
{
public:
    void Add(Object *object);
    void Remove(Object *object);
    void Update();
}

class Fire : Object
{
public:
    virtual void Update()
    {
        if(age > burnTime)
        {
            world.Remove(this);
            delete this;
        }
    }
}

这里我们有一个世界，负责管理一组对象并定期更新它们。 火是一个可以在许多不同情况下添加到世界中的对象，但通常是由世界中已有的另一个对象添加到世界中的。 火是唯一知道它何时烧毁的对象，所以目前我让它自行删除。 引发火灾的物体可能已不存在或不再相关。

这是明智的做法还是有更好的设计可以帮助清理这些物体？

Answer 1

它当然适用于由 new 创建的对象，并且当 Update 的调用者被正确告知该行为时。 但我会避免它。 就你而言，所有权显然属于世界，所以我会让世界删除它。 该对象不会创建自身，我认为它也不应该删除自身。 如果您在对象上调用“更新”函数，但突然间该对象不再存在，而 World 本身不做任何事情（除了将其从其列表中删除之外 - 但在另一个框架中），这可能会非常令人惊讶！调用的代码对对象的更新不会注意到这一点）。

关于此的一些想法

1. 添加对 World 的对象引用列表。 该列表中的每个对象都等待删除。 这是一种常见的技术，在 wxWidgets 中用于已关闭但仍可能接收消息的顶级窗口。 在空闲时间，当处理完所有消息后，处理挂起列表，并删除对象。 我相信 Qt 遵循类似的技术。
2. 告诉世界该对象想要被删除。 世界将得到适当的通知，并将处理任何需要做的事情。 也许类似于 deleteObject(Object&) 。
3. 向每个对象添加一个 shouldBeDeleted 函数，如果该对象希望被其所有者删除，该函数将返回 true。

我更喜欢选项 3。世界会调用更新。 之后，它会查看该对象是否应该被删除，并且可以这样做 - 或者如果它愿意，它会通过手动将该对象添加到待删除列表来记住这一事实。

当您无法确定何时以及何时不能访问对象的函数和数据时，这是一件很痛苦的事情。 例如，在wxWidgets中，有一个wxThread类，它可以以两种模式运行。 其中一种模式（称为“可分离”）是，如果其主函数返回（并且应该释放线程资源），则它会删除自身（以释放 wxThread 对象占用的内存），而不是等待线程的所有者对象调用等待或加入函数。 然而，这会导致严重的头痛。 你永远不能调用它的任何函数，因为它在任何情况下都可能被终止，并且你不能不使用 new 创建它。 很多人告诉我他们非常不喜欢它的这种行为。

引用计数对象的自删除是有味道的，恕我直言。 让我们比较一下：

// bitmap owns the data. Bitmap keeps a pointer to BitmapData, which
// is shared by multiple Bitmap instances. 
class Bitmap {
    ~Bitmap() {
        if(bmp->dec_refcount() == 0) {
            // count drops to zero => remove 
            // ref-counted object. 
            delete bmp;
        }
    }
    BitmapData *bmp;
};

class BitmapData {
    int dec_refcount();
    int inc_refcount();

};

与自删除引用计数对象进行比较：

class Bitmap {
    ~Bitmap() {
        bmp->dec_refcount();
    }
    BitmapData *bmp;
};

class BitmapData {
    int dec_refcount() {
        int newCount = --count;
        if(newCount == 0) {
            delete this;
        }
        return newCount;
    }
    int inc_refcount();
};

我认为第一个要好得多，而且我相信设计良好的引用计数对象不会“删除这个”，因为它增加了耦合：使用引用计数数据的类必须知道并记住数据会删除自身，这是减少引用计数的副作用。 请注意“bmp”如何可能成为 ~Bitmap 析构函数中的悬空指针。 可以说，不这样做“删除这个”在这里要好得多。

回答类似问题“删除这个有什么用”

Answer 2

其他人提到了“删除此”的问题。 简而言之，既然“世界”管理着火的创造，那么它也应该管理着火的删除。

另一个问题是，世界末日是否会伴随着仍在燃烧的大火。 如果这是扑灭火灾的唯一机制，那么最终可能会引发孤立火灾或垃圾火灾。

对于您想要的语义，我将在您的“Fire”类（或对象，如果适用）中有一个“活动”或“活动”标志。 然后，世界有时会检查其物品清单，并清除不再活跃的物品。

--

还要注意的是，您所编写的代码具有从 Object 私有继承的 Fire，因为这是默认设置，尽管它比公共继承要少得多。 您可能应该明确指定继承类型，并且我怀疑您确实想要公共继承。

Answer 3

除非有必要或以非常简单的方式使用，否则“删除此”通常不是一个好主意。 在您的情况下，世界看起来可以在删除对象时删除该对象，除非存在我们没有看到的其他依赖项（在这种情况下，您的删除调用将导致错误，因为它们没有被通知）。 将所有权保留在对象之外可以使对象更好地封装并且更稳定：对象不会仅仅因为选择删除自身而在某个时刻变得无效。

Answer 4

我不认为对象删除自身有什么本质上的错误，但另一种可能的方法是让世界负责删除对象作为 ::Remove 的一部分（假设所有已删除的对象也被删除。）

Answer 5

这是一个相当常见的引用计数实现，我之前已经成功使用过。

但是，我也看到它崩溃了。 我希望我能记得坠机的情况。 @abelenky 是我见过它崩溃的地方。

它可能是您进一步子类化 Fire 的地方，但无法创建虚拟析构函数（见下文）。 当您没有虚拟析构函数时，Update() 函数将调用 ~Fire() 而不是相应的析构函数 ~Flame() >。

class Fire : Object
{
public:
    virtual void Update()
    {
        if(age > burnTime)
        {
            world.Remove(this);
            delete this; //Make sure this is a virtual destructor.
        }
    }
};

class Flame: public Fire
{
private: 
    int somevariable;
};

Answer 6

删除这个是非常危险的。 这没有什么“问题”。 这是合法的。 但使用它时可能会出现很多问题，因此应谨慎使用。

考虑这样的情况：某人打开了该对象的指针或引用，然后它自行删除。

在大多数情况下，我认为对象生命周期应该由创建它的同一个对象来管理。 它只是让人们更容易知道破坏发生在哪里。

Answer 7

在 C++ 中对象删除自身并没有什么问题，大多数引用计数的实现都会使用类似的东西。 然而，它被视为一种有点深奥的技术，您需要密切关注所有权问题。

Answer 8

如果对象没有用new分配和构造，删除将会失败，并且可能导致程序崩溃。 此构造将阻止您在堆栈上或静态地实例化该类。 就您而言，您似乎正在使用某种分配方案。 如果你坚持这样做，这可能是安全的。 但我当然不会这么做。

Answer 9

我更喜欢更严格的所有权模式。 世界应该拥有其中的物体并负责清理它们。 要么让 world remove 执行此操作，要么让 update（或其他函数）返回一个指示应删除对象的值。

我还猜测，在这种类型的模式中，您将需要对对象进行引用计数，以避免出现悬空指针。

Answer 10

您已将 Update 设为虚函数，这表明派生类可以重写 Update 的实现。 这带来了两大风险。

1.) 重写的实现可能会记得执行World.Remove，但可能会忘记delete this。 内存泄露了。

2.) 重写的实现调用基类Update，它执行delete this，但随后继续进行更多工作，但 this 指针无效。

考虑这个例子：

class WizardsFire: public Fire
{
public:
    virtual void Update()
    {
        Fire::Update();  // May delete the this-object!
        RegenerateMana(this.ManaCost); // this is now invaild!  GPF!
    }
}

Answer 11

这样做的问题是，您实际上是在对象和 World 类之间创建了隐式耦合。

如果我尝试在 World 类之外调用 Update() ，会发生什么？ 我可能最终会删除该对象，但我不知道为什么。 看来责任严重混淆了。 当您在编写此代码时未曾想到的新情况下使用 Fire 类时，这将导致问题。 如果要从多个位置删除对象会发生什么情况？ 也许它应该从世界、当前地图和玩家的库存中删除？ 您的更新功能会将其从世界中删除，然后删除该对象，下次地图或库存尝试访问该对象时，就会发生坏事。

一般来说，我认为 Update() 函数删除它正在更新的对象是非常不直观的。 我还想说，对象删除自身是不直观的。
该对象更可能应该有某种方式来触发一个事件，表明它已完成燃烧，任何感兴趣的人现在都可以对此采取行动。 例如，将其从世界上删除。 要删除它，请考虑所有权。

谁拥有该对象？ 世界？ 这意味着只有世界才能决定物体何时死亡。 只要世界对该对象的引用比其他对该对象的引用持续时间就可以了。
你认为该物体拥有自己吗？ 那有什么意思？ 当对象不再存在时应该删除该对象吗？ 没有道理。

但如果没有明确定义的单一所有者，则实现共享所有权，例如使用智能指针实现引用计数，如boost::shared_ptr，

但在对象本身上有一个成员函数，这是硬编码的从一个特定列表中删除对象，无论它是否存在于该列表中，也无论它是否也存在于任何其他列表中，并且删除对象本身，无论存在哪些对它的引用，是一个坏主意。