显式调用析构函数 [英] Explicit call to destructor
问题描述
我偶然发现了以下代码片段:
I stumbled upon the following code snippet:
#include <iostream>
#include <string>
using namespace std;
class First
{
string *s;
public:
First() { s = new string("Text");}
~First() { delete s;}
void Print(){ cout<<*s;}
};
int main()
{
First FirstObject;
FirstObject.Print();
FirstObject.~First();
}
文字说这个片段应该导致运行时错误.现在，我不太确定，所以我尝试编译并运行它.有效.奇怪的是，尽管所涉及的数据很简单，但程序在打印文本"后卡顿，仅在一秒钟后完成.
The text said that this snippet should cause a runtime error. Now, I wasn't really sure about that, so I tried to compile and run it. It worked. The weird thing is, despite the simplicity of the data involved, the program stuttered after printing "Text" and only after one second it completed.
我添加了一个要打印到析构函数的字符串，因为我不确定显式调用这样的析构函数是否合法.程序打印了两次字符串.所以我的猜测是析构函数被调用两次，因为正常的程序终止不知道显式调用并尝试再次销毁对象.
I added a string to be printed to the destructor as I was unsure if it was legal to explicitly call a destructor like that. The program printed twice the string. So my guess was that the destructor is called twice as the normal program termination is unaware of the explicit call and tries to destroy the object again.
一个简单的搜索证实，在自动化对象上显式调用析构函数是危险的，因为第二次调用(当对象超出范围时)具有未定义的行为.所以我很幸运有我的编译器(VS 2017)或这个特定的程序.
A simple search confirmed that explicitly calling a destructor on an automated object is dangerous, as the second call (when the object goes out of scope) has undefined behaviour. So I was lucky with my compiler (VS 2017) or this specific program.
关于运行时错误的文字是错误的吗?或者运行时错误真的很常见吗?或者我的编译器可能对这种事情实施了某种保护机制?
Is the text simply wrong about the runtime error? Or is it really common to have runtime error? Or maybe my compiler implemented some kind of warding mechanism against this kind of things?
推荐答案
一个简单的搜索证实，在自动化对象上显式调用析构函数是危险的，因为第二次调用(当对象超出范围时)具有未定义的行为.
A simple search confirmed that explicitly calling a destructor on an automated object is dangerous, as the second call (when the object goes out of scope) has undefined behaviour.
确实如此.如果您显式销毁具有自动存储的对象，则会调用未定义行为.了解详情.
That is true. Undefined Behavor is invoked if you explicitly destroy an object with automatic storage. Learn more about it.
所以我很幸运有我的编译器(VS 2017)或这个特定的程序.
So I was lucky with my compiler (VS 2017) or this specific program.
我会说你倒霉.UB 可能发生的最好的(对你来说，编码器)是第一次运行时崩溃.如果它看起来工作正常，那么崩溃可能会在 2038 年 1 月 19 日在生产中发生.
I'd say you were unlucky. The best (for you, the coder) that can happen with UB is a crash at first run. If it appears to work fine, the crash could happen in January 19, 2038 in production.
关于运行时错误的文字是错误的吗?或者运行时错误真的很常见吗?或者我的编译器可能对这种事情实施了某种保护机制?
Is the text simply wrong about the runtime error? Or is it really common to have runtime error? Or maybe my compiler implemented some kind of warding mechanism against this kind of things?
是的，文字有点错误.未定义行为未定义.运行时错误只是众多可能性中的一种(包括鼻恶魔).
Yes, the text's kinda wrong. Undefined behavior is undefined. A run-time error is only one of many possibilities (including nasal demons).
有关未定义行为的好书:什么是未定义行为?
A good read about undefined behavor: What is undefined behavor?
这篇关于显式调用析构函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
