这会导致 DLL 的不同运行时出现问题吗？

Question

我的 gui 应用程序支持多态定时事件，这意味着用户调用 new，而 gui 调用删除。如果运行时不兼容，这可能会产生问题。

所以我被告知建议的解决方案是这样的：

class base;

class Deallocator {
    void operator()(base* ptr) 
    {
        delete ptr;
    }
}

class base {
public:
base(Deallocator dealloc) 
{
    m_deleteFunc = dealloc;
}
~base() 
{
    m_deleteFunc(this);
}

private:
Deallocator m_deleteFunc;
}

int main
{
    Deallocator deletefunc;

    base baseObj(deletefunc);
}

虽然这是一个很好的解决方案，但它确实要求用户创建一个我不想要的 Deallocator 对象。然而，我想知道是否为每个派生类提供了一个 Deallocator：例如，

class derived : public base
{
  Deallocator dealloc;
public:
  Derived() : base(dealloc);
{
}
};

我认为这仍然不起作用。约束条件是： addTimedEvent() 函数是 Widget 类的一部分，该类也在 dll 中，但由用户实例化。另一个限制是一些从 Widget 派生的类使用它们自己的定时事件类调用此函数。

考虑到“调用 new 的人必须调用 delete”，考虑到这些限制，什么可以起作用？

谢谢

Answer 1

我建议您研究 COM 引用计数范例（AddRef 和 Release）。这允许更灵活的生命周期并保证使用正确的释放器，因为对象会删除自身。

请注意，如果您跨 DLL 边界共享类对象，则可能会遇到比仅使用相同分配器更大的问题。需要考虑整个单一定义规则，以及编译器之间不同的调用约定、数据布局和名称修改方案。因此，如果您想要一个可重用的库，您确实需要采用 COM 方式来执行操作，包括引用计数、自删除和仅包含纯虚函数的接口。无论您构建真正的 COM 对象还是您自己的类 COM 系统，都取决于您的其他需求。

Answer 2

首先想到的是给基类一个虚拟（抽象？）SelfDestruct 方法。假设 DLL 的使用者传递了一个他自己派生的类，他将知道如何释放它。

如果他能通过你写的课程，那么你就会遇到更多问题。我建议禁止分配此类类，并提供一个静态方法来使用您自己的分配器分配它们。

我不确定我是否已经清楚地解释了我的想法......如果没有，请询​​问，我稍后会提供代码。

Answer 3

在给定的约束下，可以将删除器函数指针与每个 TimedEvent 相关联，其中两者都被指定为 addTimedEvent 的参数。
为了减轻客户端创建自定义删除器函数的负担，您可以在小部件类的标头中提供内联删除器函数作为匿名命名空间的成员。

例如：

// Widget header

class base;
namespace {
  inline void default_deleter(base* p) 
  { 
    delete p; 
  }
}

class Widget
{
public:
  addTimedEvent(base* event, void(*deleter)(base*));
};

内联函数的优点是它将在客户端代码的上下文中编译，因此delete还将使用兼容的释放器作为客户端用于分配事件。

编辑：使删除器函数成为匿名命名空间的成员。这是避免 ODR 违规所必需的。
如果没有命名空间，您将获得两个具有相同外部名称的函数 default_deleter（因此就链接器而言它们是相同的），但具有不同的语义，因为它们引用不同的释放器。< br>
使用匿名命名空间，default_deleter 的所有实例都成为链接器的单独实体。这有一个（不幸的）副作用，即您不能再使用该函数作为 addTimedEvent 的默认参数。