在物体破坏时留下“僵尸”旗帜

Question

我想显式地销毁一个对象（调用它上面的析构函数及其所有字段），但是我可能会发现仍然有一些指向该对象的指针。 因此，我不想释放记忆; 相反，我想留下一种标志“我是一个被摧毁的对象”。

我想到了以下方法：

class BaseClass { //all objects in question derive from this class
public:
    BaseClass() : destroyed(false) {}
    virtual ~BaseClass() {}
private:
    bool destroyed;
public:
    bool isDestroyed() { return destroyed; }
    void destroy() {
        this->~BaseClass(); //this will call the virtual destructor of a derivative class
        new(this) BaseClass();
        destroyed=true;
    }
};

当调用destroy ，我基本上会破坏我拥有的任何物体（也许是衍生物）并在同一个地方创建一个新的“僵尸”。 因此，我希望实现：

• 之前指向此对象的任何其他指针ptr仍然可以调用ptr->isDestroyed()来验证它的存在。
• 我知道如果我不检查僵尸的标志并尝试访问属于任何派生对象的字段，可能会发生不好的事情
• 我知道僵尸对象仍然消耗与被破坏对象一样多的内存（因为它可能是BaseClass的衍生物）
• 我仍然需要释放被破坏物体的记忆。 但是我希望调用delete仍然正确吗？

问题：

使用上述模式时是否还有其他问题需要考虑？

在僵尸对象上调用delete会正确地释放前一个（普通）对象消耗的整个内存吗？

---

虽然我很感激您对如何以不同方式进行操作的意见，我可能倾向于按照您的方式进行操作 - 我仍然希望了解上述代码带来的所有风险。

Answer 1

有一个使用智能指针的建议。 事实上 - 我这样做，但我的推荐是循环的。 我可以使用一些成熟的垃圾收集器，但由于我知道自己在哪里（以及什么时候！）圈链可以被打破，我想自己利用它。

然后你可以显式null-ify（如果你使用shared_ptr 重置 ）一个循环智能指针并打破循环。

或者，如果你事先知道周期的位置，你也应该使用weak_ptr代替一些shared_ptr来提前避免它们。

---编辑---

如果弱指针引用的对象只会被标记为“无效”并释放对其所有包含指针的控制（这句话是否清楚？），我会很高兴。

那么weak_ptr::expired应该会让你开心:)

Answer 2

你对你的问题有一些讨厌的评论。 现在我不认为他们是应得的，尽管可能有更好的方法来做你想要的。 我知道你来自哪里，但实际上你使用的是析构函数，就像使用你拒绝写的重置函数一样。 实际上你从调用析构函数中得不到什么，因为调用析构函数与实际删除或重置任何东西无关，除非你实际编写代码在析构函数中执行它。

至于您关于新展示位置的问题：

您可能已经知道，placement new不会分配任何内存，因此调用它只会在同一个地方创建对象。 我明白这正是你想要的，但它不是必需的。 由于你没有在对象上调用delete只是destroy，你可以在不初始化类的情况下将destroy设置为true。

把它们加起来：

1. 如果你使用析构函数作为常规虚函数，你什么也得不到。 不要这样做，因为如果两次调用析构函数你会遇到麻烦
2. 对placement new的调用不会分配内存，只是执行不必要的初始化。 你可以将destroy设置为true。

要执行您想要正确执行的操作并获得析构函数的好处，您应该重载类的new和delete操作符并使用正常的销毁机制。 然后，您可以选择不释放内存，但将其标记为无效或可能释放大部分内存，但将指针指向某些标记。

编辑

在评论之后，我决定总结我看到的所有风险以及其他人指出的风险：

1. 在多线程环境中访问无效指针：使用您的方法，可以在析构函数运行之后但在设置destroy标记之前访问类（关于您在其中一条注释中的问题 - shared_ptr对于大多数用途是线程安全的）
2. 中继您不完全控制的行为：您的方法依赖于析构函数自动调用未动态分配的其他成员的析构函数的方式：这意味着您仍然必须释放动态分配内存，您无法控制如何确切地说，这是实现的，您无法控制调用其他析构函数的顺序。
3. 转换你并不完全控制的行为（第2点）：你正在转发编译器实现析构函数部分的方式，这个析构函数调用其他析构函数你无法告诉你的代码是否可移植，甚至是如何处理它两次。
4. 可以调用两次析构函数：根据您的实现，这可能会导致内存泄漏或堆损坏，除非您防止两次释放相同的内存。 您声称通过调用新的位置来防范这种情况 - 但是在多线程环境中，这不能保证更多的假设所有内存分配都是由默认构造函数完成的 - 这取决于您的具体实现，这可能是也可能不是真正。
5. 你反对对每个回答你问题的人提出更好的判断或评论它 - 你可能会遇到一些天才，但很可能你只是通过将你的实现限制在可以正常工作的一小部分情况下来拍摄自己。 。 就像使用错误的螺丝刀一样，最终会损坏螺丝。 以同样的方式使用语言构造它不打算使用可能最终导致错误的程序 - 析构函数旨在从删除和编译器生成的代码中调用以清除堆栈。 直接使用它并不明智。

我重复我的建议 - 重载删除和新的你想要的

Answer 3

和其他人一样，我建议您只使用weak_ptr 。 但你问为什么你的方法不起作用。 你的代码遍布全局，有一些优雅实现和关注点分离的问题，但我不会争论这些问题。 相反，我只是指出你的代码非常不是线程安全的。

考虑以下两个控制线程的执行顺序：

// Thread One
if ( ! ptr -> isDestroyed() ) {     // Step One
    // ... interruption ...
    ptr -> something();             // Step Three

和另一个：

// Thread Two
ptr -> destroy();                   // Step Two

到第3步到来时，指针不再有效。 现在可以通过实现lock()或类似方法来解决这个问题，但现在你已经发生了关于不释放锁的缺陷的可能性。 每个人都推荐weak_ptr的原因是这类问题已经在类的接口和它的实现中得到了解决。

还有一个问题。 你似乎想要一个可以随意杀死一个物体的设施。 这等于要求对象的唯一指针是弱对象，没有强对象指针在手动删除对象时会破坏。 （我会规定这不是一个坏主意，但我必须说我不知道​​为什么它不在你的情况下。）你可以通过建立在weak_ptr和shared_ptr之weak_ptr获得这个。 这些类是通用的，因此如果您想禁止对BaseClass shared_ptr访问，那么您可以为shared_ptr<BaseClass>编写一个行为不同的特化。 隐藏shared_ptr<BaseClass>一个实例以防止删除，并通过您控制下的工厂方法提供此类指针。

在这个模型中， destroy()的语义需要注意。 第一种选择是您是想要同步还是异步操作。 同步destroy()将阻塞，直到释放所有外部指针并且不允许发出新指针。 （我假设指针上已经禁用了复制构造函数。）有两种异步destroy() 。 如果仍存在外部引用，则两者中较简单的失败。 在隐藏的shared_ptr() unique()上调用unique()使得这个实现变得简单。 更复杂的一个就像异步I / O调用一样，将破坏安排在将来的某个时刻发生，大概一旦所有外部引用都消失了。 此函数可能被称为mark_for_death()以反映语义，因为对象可能会或可能不会在返回时被销毁。

Answer 4

我会考虑使用一个适当的智能指针模式。 访问已删除对象的行为仍未定义，“僵尸”标志无法提供帮助。 与已删除的对象实例关联的内存可能会被创建的任何其他对象立即占用，因此访问zombie标志不是您可以信任的信息。

恕我直言新的运营商

new(this) BaseClass();

在destroy()方法中使用它不会真正有用。 取决于该方法的使用方法。 而不是删除已删除对象的派生对象或内部析构函数。 在后一种情况下，无论如何都将释放内存。

更新：

根据你的编辑，使用共享指针/弱指针习语来解决循环引用的出现不是更好。 我会认为这些是一个设计缺陷。