虚拟析构函数和未定义的行为

发布于 2024-12-22 16:05:00 字数 550 浏览 4 评论 0原文

这个问题与“何时/为什么我应该使用虚拟析构函数?”不同。

struct B {
  virtual void foo ();
  ~B() {}  // <--- not virtual
};
struct D : B {
  virtual void foo ();
  ~D() {}
};
B *p = new D;
delete p;  // D::~D() is not called

问题

  1. 这是否可以归类为未定义行为(我们知道~D()肯定不会被调用)?
  2. 如果 ~D() 为空怎么办?它会以任何方式影响代码吗?
  3. new[]/delete[]B* p; 一起使用时,~D() 肯定会不是 被调用,无论析构函数的虚拟性如何。是吗 未定义的行为还是明确定义的行为?

This question is different than 'When/why should I use a virtual destructor?'.

struct B {
  virtual void foo ();
  ~B() {}  // <--- not virtual
};
struct D : B {
  virtual void foo ();
  ~D() {}
};
B *p = new D;
delete p;  // D::~D() is not called

Questions:

  1. Can this be classified as an undefined behavior (we are aware that ~D() is not going to be called for sure)?
  2. What if ~D() is empty. Will it affect the code in any way?
  3. Upon using new[]/delete[] with B* p;, the ~D() will certainly not
    get called, irrespective of virtualness of the destructor. Is it
    an undefined behavior or well defined behavior?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

哑剧 2024-12-29 16:05:00

何时/为何应使用虚拟析构函数?
遵循 Herb Sutters 指南

基类析构函数应该是公共的和虚拟的,或者是受保护的和非虚拟的

这可以归类为未定义的行为吗(我们知道〜D()肯定不会被调用)?

它根据标准,这是未定义的行为,这通常会导致派生类析构函数不被调用并导致内存泄漏,但推测未定义行为的后续影响是无关紧要的,因为标准不保证任何事情在这方面。

C++03 标准:5.3.5 删除

5.3.5/1:

删除表达式运算符会销毁由新表达式创建的最派生对象 (1.8) 或数组。
删除表达式:
::opt 删除强制转换表达式
::opt删除[]强制转换表达式

5.3.5/3:

在第一种选择(删除对象)中,如果操作数的静态类型与其动态类型不同,则静态类型应为操作数动态类型的基类,并且静态类型应具有虚拟类型析构函数或行为未定义。在第二种选择(删除数组)中,如果要删除的对象的动态类型与其静态类型不同,则行为未定义。73)

如果 ~D( )是空的。它会以任何方式影响代码吗?
根据标准,它仍然是未定义的行为,派生类析构函数为空可能只会使您的程序正常工作,但这又是特定实现的实现定义方面,从技术上讲,它仍然是未定义的行为。

请注意,这里不能保证不将派生类析构函数设为虚拟就不会导致对派生类析构函数的调用,并且这种假设是不正确的。根据标准,一旦您进入“未定义行为”区域,所有投注均无效。

请注意他的标准对未定义行为的说法。

C++03 标准:1.3.12 未定义行为 [defns.undefined]

行为,例如由于使用错误的程序构造或错误的数据而可能出现的行为,本国际标准对此没有强加任何要求。当本国际标准省略任何明确的行为定义的描述时,也可能会出现未定义的行为。 [注意:允许的未定义行为范围包括完全忽略结果不可预测的情况,到在
以环境特征的记录方式进行翻译或程序执行(发出或不发出诊断消息),到终止翻译或执行(发出诊断消息)。许多错误的程序构造不会产生未定义的行为;他们需要被诊断。
]

如果仅不调用派生析构函数,则由上面引用中的粗体文本控制,这显然对每个实现都是开放的。

when/why should I use a virtual destructor?
Follow Herb Sutters guideline:

A base class destructor should be either public and virtual, or protected and nonvirtual

Can this be classified as an undefined behavior (we are aware that ~D() is not going to be called for sure) ?

It is Undefined Behavior as per the standard, which usually results in the Derived class destructor not being called and resulting in a memory leak, but it is irrelevant to speculate on after effetcs of an Undefined Behavior because standard doesn't gaurantee anything in this regard.

C++03 Standard: 5.3.5 Delete

5.3.5/1:

The delete-expression operator destroys a most derived object (1.8) or array created by a new-expression.
delete-expression:
::opt delete cast-expression
::opt delete [ ] cast-expression

5.3.5/3:

In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.73)

What if ~D() is empty. Will it affect the code in any way ?
Still it is Undefined Behavior as per the standard, The derived class destructor being empty may just make your program work normally but that is again implementation defined aspect of an particular implementation, technically, it is still an Undefined Behavior.

Note that there is no gaurantee here that not making the derived class destructor virtual just does not result in call to derived class destructor and this assumption is incorrect. As per the Standard all bets are off once you are crossed over in Undefined Behavior land.

Note what he standard says about Undefined Behavior.

The C++03 Standard: 1.3.12 undefined behavior [defns.undefined]

behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
]

If only derived destructor will be not called is governed by the bold text in the above quote, which is clearly left open for each implementation.

撑一把青伞 2024-12-29 16:05:00
  1. 未定义的行为
  2. 首先要注意的是,这些解构函数通常并不像您想象的那么空。您仍然必须解构所有成员)即使解构函数确实是空的(POD?),那么它仍然取决于你的编译器。标准未定义它。对于所有标准的关心,您的计算机可能会在删除时崩溃。
  3. 未定义的行为

在要继承的类中确实没有理由使用非虚拟公共析构函数。请参阅本文,指南#4。

使用受保护的非虚拟析构函数和shared_ptrs(它们具有静态链接)或公共虚拟析构函数。

  1. Undefined Behavior
  2. (One first note, these deconstructors are generally not as empty as you would think. You still have to deconstruct all of your members) Even if the deconstructor is truly empty(POD?), then it still depends on your compiler. It is undefined by the standard. For all the standard cares your computer could blow up on the delete.
  3. Undefined Behavior

There really is no reason for a non-virtual public destructor in a class that is meant to be inherited from. Look at this article, Guideline #4.

Use either a protected non-virtual destructor and shared_ptrs(they have static linking), or a public virtual destructor.

悲念泪 2024-12-29 16:05:00

正如其他人所重申的,这是完全未定义的,因为 Base 的析构函数不是虚拟的,任何人都不能发表任何声明。请参阅此帖子以获取标准参考和进一步讨论。

(当然,各个编译器有权做出某些承诺,但在这种情况下我还没有听说过任何相关内容。)

不过我觉得很有趣,在这种情况下我认为 malloc 和 <在某些情况下,code>free 的定义比 newdelete 更好。也许我们应该使用它们:-)

给定一个基类和一个派生类,它们都没有任何虚拟方法,定义如下:

Base * ptr = (Base*) malloc(sizeof(Derived)); // No virtual methods anywhere
free(ptr); // well-defined

如果 D 有复杂的额外内容,则可能会发生内存泄漏成员,但除此之外,这是定义的行为。

As reaffirmed by others this is totally undefined because the Base's destructor is not virtual, and no statements can be made by anybody. See this thread for a reference to the standard and further discussion.

(Of course, individual compilers are entitled to make certain promises, but I haven't heard anything about that in this case.)

I find it interesting though, that in this case I think that malloc and free are better defined in some cases than new and delete. Perhaps we should be using those instead :-)

Given a base class and a derived class, neither of which have any virtual methods, the following is defined:

Base * ptr = (Base*) malloc(sizeof(Derived)); // No virtual methods anywhere
free(ptr); // well-defined

You might get a memory leak if D had complex extra members, but apart from this is is defined behaviour.

蓬勃野心 2024-12-29 16:05:00

(我想我可能会删除我的其他答案。)

有关该行为的所有内容都是未定义的。如果您想要更好地定义行为,您应该研究shared_ptr,或者自己实现类似的东西。以下是定义的行为,无论任何东西的虚拟性如何:

    shared_ptr<B> p(new D);
    p.reset(); // To release the object (calling delete), as it's the last pointer.

shared_ptr 的主要技巧是模板化构造函数。

(I think I might delete my other answer.)

Everything about that behaviour is undefined. If you want better defined behaviour, you should look into shared_ptr, or implement something similar yourself. The following is defined behaviour, regardless of the virtual-ness of anything:

    shared_ptr<B> p(new D);
    p.reset(); // To release the object (calling delete), as it's the last pointer.

The main trick of shared_ptr is the templated constructor.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文