Within any non-static member function, this points to the object that the function was called on. It’s safe to use as long as that’s a valid object. Within the body of a constructor or destructor, there is a valid object of the class currently being constructed. However, if this is the base sub-object of some … Read more
Herfried Wagner has written an excellent article explaining how to implement this – alas, in German (and VB). Still, the code should be understandable. I’ve tried it: static readonly Finalizer finalizer = new Finalizer(); sealed class Finalizer { ~Finalizer() { Thread.Sleep(1000); Console.WriteLine(“one”); Thread.Sleep(1000); Console.WriteLine(“two”); Thread.Sleep(1000); Console.WriteLine(“three”); Thread.Sleep(1000); Console.WriteLine(“four”); Thread.Sleep(1000); Console.WriteLine(“five”); } } It seems to … Read more
It seems to me that we can call destructor explicitly in this case, could you explain to me why? Do you mean why can we? Because the language allows explicit destructor calls on any object. As you say, it usually gives undefined behaviour since most objects will be destroyed in some other way, and it’s … Read more
The simplest solution is to put a named struct instance as a member in the unnamed one, and put all of the functionality into the named instance. This is probably the only way that is compatible with C++98. #include <iostream> #include <cmath> int main() { struct { struct S { double a; int b; S() … Read more
The short answer is: no. C++ does not employ garbage collection, like Java or C#. When an object is destroyed, it’s destroyed immediately. Gone for good. Joined the choir invisible. Pining for the fjords, etc… And to say this over a couple of times in different words so that there is no possible weasily reinterpretation… … Read more
Are there any other circumstances where they[destructors] will not be called? Long jumps: these interfere with the natural stack unwinding process and often lead to undefined behavior in C++. Premature exits (you already pointed these out, though it’s worth noting that throwing while already stack unwinding as a result of an exception being thrown leads … Read more
The comment is not correct. Both: virtual ~A() = default; and virtual ~A() {} are user declared. And the implicit move members are inhibited if the destructor is user declared. [dcl.fct.def.default]/p4 discusses user-declared and user-provided special members: A special member function is user-provided if it is user-declared and not explicitly defaulted or deleted on its … Read more
Yes, automatic variables will be destroyed at the end of the enclosing code block. But keep reading. Your question title asks if a destructor will be called when the variable goes out of scope. Presumably what you meant to ask was: will Foo’s destructor be called at the end of main()? Given the code you … Read more
MDN is a nice resource for JS. No, there is nothing like calling a function when an object ceases.
No, by default, most signals cause an immediate, abnormal exit of your program. However, you can easily change the default behavior for most signals. This code shows how to make a signal exit your program normally, including calling all the usual destructors: #include <iostream> #include <signal.h> #include <unistd.h> #include <cstring> #include <atomic> std::atomic<bool> quit(false); // … Read more