【问题标题】:Preventing a hierarchy of classes from being created on the stack防止在堆栈上创建类的层次结构
【发布时间】:2012-11-23 02:24:49
【问题描述】:

我不确定这是否可能。

我需要防止从 X 派生的所有类被实例化为本地堆栈或成员变量。我使他们所有的析构函数都受到保护,就外部范围而言,这起到了作用。但是,我也需要防止它们被自己实例化。我的意思是,如果 Y 具有 Z 类型的成员变量或在其方法中实例化 Z 类型的局部变量,则不会削减它。

现在我可以在层次结构树的所有叶子中创建私有析构函数,但问题是每个 not 都应该被允许成为(堆)变量。在 X

我想通过将它们的构造函数设为私有并将 operator new 添加为所有它们的朋友会解决问题,但这是很多额外的工作(因为我们使用了 operator new 的多个版本)并且层次结构很大。

那么,有没有办法在不使用 private-constructors-friend-new-way 的情况下,使这些对象的堆栈实例化出现(最好)编译时或运行时错误?

问题是这个项目的以前的程序员写了大量的代码,这个层次结构中的所有类都有非常复杂的析构函数。而且,作者在这些 destructros 中不加选择地调用了虚拟方法,这导致了很多(对他们而言)无法解释的崩溃和内存损坏。现在将所有析构函数转换为obj->Release() 模式,在最顶层的版本中我有delete this。显然这不适用于堆栈对象,现在我介绍了一些我自己的崩溃。另外我的时间有点短,运行/等待崩溃/修复这个特定的崩溃方法非常非常慢 编辑>

【问题讨论】:

  • 我认为变量所在的位置取决于您如何声明它?
  • 一个对象通常不应该关心它是如何存储的。这违反了单一职责的习惯用法。您要问的是对语言的严重滥用,所以我不希望答案很漂亮。

标签: c++ inheritance constructor destructor


【解决方案1】:

在他的书“更有效的 C++”第 27 项中,Scott Meyers(顺便说一句,我最喜欢的 C++ 作家)描述了为什么在一般意义上以及在可移植或半可移植 C++ 的范围内不可能明确区分一个对象已在堆栈、堆上分配或静态分配。它还讨论了确保对象只能在堆栈或堆上分配的各种选项。其中一个或多或少是可行的,另一个没有真正便携的万无一失的工作方式;我忘了哪个是哪个。 (书在上班,我在家。)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-12-22
    • 2011-12-16
    • 1970-01-01
    • 1970-01-01
    • 2012-02-13
    • 2017-04-18
    • 1970-01-01
    相关资源
    最近更新 更多