Is there a destructor for Java? I don&#39;t seem to be able to find any documentation on this. If there isn&#39;t, how can I achieve the same effect?


To make my question more specific, I am writing an application that deals with data and the specification say that there should be a &#39;reset&#39; button that brings the application back to its original just launched state. However, all data have to be &#39;live&#39; unless the application is closed or reset button is pressed.

Being usually a C/C++ programmer, I thought this would be trivial to implement. (And hence I planned to implement it last.) I structured my program such that all the &#39;reset-able&#39; objects would be in the same class so that I can just destroy all &#39;live&#39; objects when a reset button is pressed.

I was thinking if all I did was just to dereference the data and wait for the garbage collector to collect them, wouldn&#39;t there be a memory leak if my user repeatedly entered data and pressed the reset button? I was also thinking since Java is quite mature as a language, there should be a way to prevent this from happening or gracefully tackle this.

Is there a destructor for Java?

    class Package:
        def __init__(self):
            self.files = []

        # ...

        def __del__(self):
            for file in self.files:
                os.unlink(file)

`__del__(self)` above fails with an AttributeError exception.  I understand [Python doesn&#39;t guarantee](http://docs.python.org/reference/datamodel.html#customization) the existence of &quot;global variables&quot; (member data in this context?) when `__del__()` is invoked.  If that is the case and this is the reason for the exception, how do I make sure the object destructs properly?

How do I correctly clean up a Python object?

When overriding a class in C++ (with a virtual destructor) I am implementing the destructor again as virtual on the inheriting class, but do I need to call the base destructor?

If so I imagine it&#39;s something like this...

    MyChildClass::~MyChildClass() // virtual in header
    {
        // Call to base destructor...
        this-&gt;MyBaseClass::~MyBaseClass();
    
        // Some destructing specific to MyChildClass
    }

Am I right?

Do I need to explicitly call the base virtual destructor?

Most people say *never* throw an exception out of a destructor - doing so results in undefined behavior. Stroustrup makes the point that *&quot;the vector destructor explicitly invokes the destructor for every element. This implies that if an element destructor throws, the vector destruction fails... There is really no good way to protect against exceptions thrown from destructors, so the library makes no guarantees if an element destructor throws&quot; (from Appendix E3.2)*.

[This article][1] seems to say otherwise - that throwing destructors are more or less okay.

*So my question is this - if throwing from a destructor results in undefined behavior, how do you handle errors that occur during a destructor?*

If an error occurs during a cleanup operation, do you just ignore it? If it is an error that can potentially be handled up the stack but not right in the destructor, doesn&#39;t it make sense to throw an exception out of the destructor?

Obviously these kinds of errors are rare, but possible.


  [1]: http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml

If you shouldn&#39;t throw exceptions in a destructor, how do you handle errors in it?

What is the use of having destructor as private?

For example:


    public class Person
    {
        public Person()
        {
        }
    
        ~Person()
        {
        }
    }


When should I manually create a destructor?
When have you needed to create a destructor? 

When should I create a destructor?

Is it wrong to write:

    class A {
    public:
        virtual ~A() = 0;
    };

for an abstract base class?

At least that compiles in MSVC... Will it crash at run time?



Pure virtual destructor in C++

I have an `class A` which uses a heap memory allocation for one of its fields. Class A  is instantiated and stored as a pointer field in another class (`class B`.

When I&#39;m done with an object of class B, I call `delete`, which I assume calls the destructor... But does this call the destructor of class A as well?

### Edit:
From the answers, I take that (please edit if incorrect):

1. `delete` of an instance of B calls B::~B();
2. which calls `A::~A();`
3. `A::~A` *should* explicitly `delete` all heap-allocated member variables of the A object;
4. Finally the memory block storing said instance of class B is returned to the heap - when *new* was used, it first allocated a block of memory on heap, then invoked constructors to initialize it, now after all destructors have been invoked to finalize the object the block where the object resided is returned to the heap.

Does delete on a pointer to a subclass call the base class destructor?

I understand the need for a virtual destructor. But why do we need a ***pure*** virtual destructor? In one of the C++ articles, the author has mentioned that we use pure virtual destructor when we want to make a class abstract. 

But we can make a class abstract by making any of the member functions as pure virtual. 

So my questions are 
 
1. When do we really make a destructor pure virtual? Can anybody give a good real time example? 

2. When we are creating abstract classes is it a good practice to make the destructor also pure virtual? If yes..then why?




Why do we need a pure virtual destructor in C++?

Basic Question: when does a program call a class&#39; destructor method in C++? I have been told that it is called whenever an object goes out of scope or is subjected to a `delete`

More specific questions:

1) If the object is created via a pointer and that pointer is later deleted or given a new address to point to, does the object that it was pointing to call its destructor (assuming nothing else is pointing to it)?

2) Following up on question 1, what defines when an object goes out of scope (not regarding to when an object leaves a given {block}). So, in other words, when is a destructor called on an object in a linked list?

3) Would you ever want to call a destructor manually?

When is a C++ destructor called?

As far as I know (which is very little) , there are two ways, given:

    $var = new object()

Then:

    // Method 1: Set to null
    $var = null;
    // Method 2: Unset 
    unset($var); 
 

Other better method? Am I splitting hairs here?

How to destroy an object?

&gt; **Possible Duplicate:**  
&gt; [What is difference between instantiating an object using new vs. without](https://stackoverflow.com/questions/3673998/what-is-difference-between-instantiating-an-object-using-new-vs-without)  

&lt;!-- End of automatically inserted text --&gt;

This is probably a basic question, and might have already been asked (say, [here](https://stackoverflow.com/q/2494471/459391)); yet I still don&#39;t understand it. So, let me ask it.

Consider the following C++ class:

    class Obj{
        char* str;
    public:
        Obj(char* s){
            str = s;
    		cout &lt;&lt; str;
        }
        ~Obj(){
    		cout &lt;&lt; &quot;Done!\n&quot;;
            delete str;        // See the comment of &quot;Loki Astari&quot; below on why this line of code is bad practice
        }
    };

what&#39;s the difference between the following code snippets:

    Obj o1 (&quot;Hi\n&quot;);

and

    Obj* o2 = new Obj(&quot;Hi\n&quot;);

Why the former calls the destructor, but the latter doesn&#39;t (without explicit call to `delete`)?

Which one is preferred?

Creating an object: with or without `new`

When would I implement IDispose on a class as opposed to a destructor?  I read [this article][1], but I&#39;m still missing the point.  

My assumption is that if I implement IDispose on an object, I can explicitly &#39;destruct&#39; it as opposed to waiting for the garbage collector to do it.  Is this correct?

Does that mean I should always explicitly call Dispose on an object?  What are some common examples of this?


  [1]: http://www.dotnetspider.com/resources/1382-Understanding-IDisposable-pattern.aspx

What is the difference between using IDisposable vs a destructor in C#?

What is the difference, if there is one, between a destructor and a Finalize method in a class?

I recently discovered that Visual Studio 2008 considers a destructor synonymous with a Finalize method, meaning that Visual Studio won&#39;t let you simultaneously define both methods in a class.

For example, the following code fragment:

    class TestFinalize
    {
        ~TestFinalize()
        {
            Finalize();
        }

        public bool Finalize()
        {
            return true;
        }
    }


Gives the following error on the call to Finalize in the destructor: 

&gt;The call is ambiguous between the following methods or properties:
        &#39;TestFinalize.~TestFinalize()&#39; and &#39;TestFinalize.Finalize()&#39;

And if the call to Finalize is commented out, it gives the following error:

&gt;Type &#39;ManagementConcepts.Service.TestFinalize&#39; already defines a member called 
    &#39;Finalize&#39; with the same parameter types


In C# what is the difference between a destructor and a Finalize method in a class?

Developing environment: GNU GCC (g++) 4.1.2

While I&#39;m trying to investigate how to increase &#39;code coverage - particularly function coverage&#39; in unit testing, I&#39;ve found that some of class dtor seems to be generated multiple times. Does some of you have any idea on why, please?

I tried and observed what I mentioned the above by using the following code.

In &quot;test.h&quot;

    class BaseClass
    {
    public:
    	~BaseClass();
    	void someMethod();
    };
    
    class DerivedClass : public BaseClass
    {
    public:
    	virtual ~DerivedClass();
    	virtual void someMethod();
    };

In &quot;test.cpp&quot;

    #include &lt;iostream&gt;
    #include &quot;test.h&quot;
    
    BaseClass::~BaseClass()
    {
    	std::cout &lt;&lt; &quot;BaseClass dtor invoked&quot; &lt;&lt; std::endl;
    }
    
    void BaseClass::someMethod()
    {
    	std::cout &lt;&lt; &quot;Base class method&quot; &lt;&lt; std::endl;
    }
    
    DerivedClass::~DerivedClass()
    {
    	std::cout &lt;&lt; &quot;DerivedClass dtor invoked&quot; &lt;&lt; std::endl;
    }

    void DerivedClass::someMethod()
    {
    	std::cout &lt;&lt; &quot;Derived class method&quot; &lt;&lt; std::endl;
    }
    
    int main()
    {
    	BaseClass* b_ptr = new BaseClass;
    	b_ptr-&gt;someMethod();
    	delete b_ptr;
    }

When I built the above code (g++ test.cpp -o test) and then see what kind of symbols have been generated as follows,

nm --demangle test

I could see the following output.

    ==== following is partial output ====
    08048816 T DerivedClass::someMethod()
    08048922 T DerivedClass::~DerivedClass()
    080489aa T DerivedClass::~DerivedClass()
    08048a32 T DerivedClass::~DerivedClass()
    08048842 T BaseClass::someMethod()
    0804886e T BaseClass::~BaseClass()
    080488f6 T BaseClass::~BaseClass()

My questions are as follows.

1) Why multiple dtors have been generated (BaseClass - 2, DerivedClass - 3)?

2) What are the difference among these dtors? How those multiple dtors will be selectively used?

I now have a feeling that in order to achieve 100% function coverage for C++ project, we would need to understand this so that I can invoke all those dtors in my unit tests.

I would greately appreciate if someone could give me the reply on the above.



GNU GCC (g++): Why does it generate multiple dtors?

[Mr. Lidstr&#246;m and I had an argument](https://stackoverflow.com/questions/3899688/default-virtual-dtor/3899726#3899726) :)

Mr. Lidstr&#246;m&#39;s claim is that a construct `shared_ptr&lt;Base&gt; p(new Derived);` doesn&#39;t require Base to have a virtual destructor:

&gt; **Armen Tsirunyan**: &quot;Really? Will the *shared_ptr* clean up correctly? Could you please in this case demonstrate how that effect could be implemented?&quot;
&gt;
&gt; **Daniel Lidstr&#246;m**: &quot;The *shared_ptr* uses its own destructor to delete the Concrete instance. This is known as RAII within the C++ community. My advice is that you learn all you can about RAII. It will make your C++ coding so much easier when you use RAII in all situations.&quot;
&gt;
&gt; **Armen Tsirunyan**: &quot;I know about RAII, and I also know that eventually the *shared_ptr* destructor may delete the stored px when pn reaches 0. But if px had static type pointer to `Base` and dynamic type pointer to `Derived`, then unless `Base` has a virtual destructor, this will result in undefined behavior. Correct me if I am wrong.&quot;
&gt; 
&gt; **Daniel Lidstr&#246;m**: &quot;The *shared_ptr* knows the static type is Concrete. It knows this since I passed it in its constructor! Seems a bit like magic, but I can assure you it is by design and extremely nice.&quot;

So, judge us. How is it possible (if it is) to implement *shared_ptr* without requiring polymorphic classes to have virtual destructor?
Thanks in advance

shared_ptr magic :)

I was thinking: they say if you&#39;re calling destructor manually - you&#39;re doing something wrong. But is it always the case? Are there any counter-examples? Situations where it is neccessary to call it manually or where it is hard/impossible/impractical to avoid it?

Is calling destructor manually always a sign of bad design?

I have found it useful to use forward declaration of classes in combination with `std::unique_ptr` as in the code below. It compiles and works with GCC, but the whole thing seem kind of strange, and I wonder if this is standard behaviour (i.e. required by the standard)? Since B isn&#39;t a complete type when I declare the `unique_ptr`.

###A.hpp
    #include &lt;memory&gt;

    class B;

    class A {
        std::unique_ptr&lt;B&gt; myptr;
        // B::~B() can&#39;t be seen from here
    public:
        ~A();
    };

###A.cpp
    #include &quot;B.hpp&quot;
    //B.hpp has to be included, otherwise it doesn&#39;t work.

    A::~A() = default; // without this line, it won&#39;t compile 
    // however, any destructor definiton will do.

I suspect this has to do with the destructor (and therefore the need to call the destructor of `unique_ptr&lt;B&gt;`) is defined in a specific compilation unit (A.cpp).

Forward declaration with unique_ptr?

In C++, if a constructor throws an exception, what destructors are run?

In particular, does it make any difference if the exception is during the initialization list or the body?

Also, what about inheritance and members?  Presumably all completed constructions get destructed.  If only some members are constructed, do only those get destructed?  If there is multiple inheritance, do all completed constructors get destructed?  Does virtual inheritance change anything?

What destructors are run when the constructor throws an exception?

VC++ makes functions which are implemented within the class declaration inline functions.

If I declare a class `Foo` as follows, then are the CONSTRUCTOR and DESTRUCTOR inline functions?

    class Foo 
    {
        int* p;
    public:
        Foo() { p = new char[0x00100000]; }
        ~Foo() { delete [] p; }
    };

    {
        Foo f;
        (f);
    }


In C++ can constructor and destructor be inline functions?

I am studying how garbage collector works in c#. I am confused over the use of `Destructor`, `Dispose` and `Finalize` methods. 

As per my research and understandings, having a Destructor method within my class will tell the garbage collector to perform the garbage collection in the way mentioned in the destructor method which cannot be called explicitly on the instances of the class. 

The `Dispose` method is meant to provide the user to control the garbage collection.  The `Finalize` method frees the resources used by the class, but not the object itself. 

I am not sure if I understand it the right way. Please clarify the doubts. Any further links or guides are welcome.


Difference between destructor, dispose and finalize method

Suppose we have a (toy) C++ class such as the following:

    class Foo {
        public:
            Foo();
        private:
            int t;
    };

Since no destructor is defined, a C++ compiler should create one automatically for class `Foo`.  If the destructor does not need to clean up any dynamically allocated memory (that is, we could reasonably rely on the destructor the compiler gives us), will defining an empty destructor, ie.

    Foo::~Foo() { }

do the same thing as the compiler-generated one? What about an empty constructor -- that is, `Foo::Foo() { }`?

If there are differences, where do they exist?  If not, is one method preferred over the other?

Will an &#39;empty&#39; constructor or destructor do the same thing as the generated one?

When exactly are objects destroyed in C++, and what does that mean? Do I have to destroy them manually, since there is no Garbage Collector? How do exceptions come into play?

&lt;sub&gt;&lt;i&gt;
(Note: This is meant to be an entry to [Stack Overflow&#39;s C++ FAQ](https://stackoverflow.com/questions/tagged/c++-faq). If you want to critique the idea of providing an FAQ in this form, then [the posting on meta that started all this](https://meta.stackexchange.com/questions/68647/setting-up-a-faq-for-the-c-tag) would be the place to do that. Answers to that question are monitored in the [C++ chatroom](https://chat.stackoverflow.com/rooms/10/c-lounge), where the FAQ idea started out in the first place, so your answer is very likely to get read by those who came up with the idea.)
&lt;/i&gt;&lt;/sub&gt;


Object destruction in C++

When creating a new instance of a `MyClass` as an argument to a function like so:

    class MyClass
    {
      MyClass(int a);
    };    
    
    myFunction(MyClass(42));

Does the standard make any guarantees on the timing of the destructor?

Specifically, can I assume that it is going to be called before the next statement after the call to `myFunction()` ?


C++: Life span of temporary arguments?

**EDIT : Summary of answers**

In the following, B is a subclass of A.

It&#39;s a matter of terminology; ctors and dtors are **not** inherited, in the sense that the ctor/dtor of B will *not* be borrowed from A&#39;s interface. A class has at least one constructor, and has exactly one destructor.

 - **Constructors**: 
  - B does not inherit constructors from A;
  - Unless B&#39;s ctor explicitely calls *one of* A&#39;s ctor, the default ctor from A will be called automatically *before* B&#39;s ctor body (the idea being that A needs to be initialized before B gets created).
 - **Destructors**:
  - B does not inherit A&#39;s dtor;
  - *After* it exits, B&#39;s destructor will automatically call A&#39;s destructor.


*Acknowledgements:*
I would like to thank especially Oli Charlesworth and Kos for their answers, I set Kos&#39; answer as the solution because it was the one I understood best.

----------

**ORIGINAL POST**

When you search for &quot;C++ destructor inheritance site:stackoverflow.com&quot; on Google, you currently find the following posts:

 1.  https://stackoverflow.com/questions/8103805/constructor-and-destructor-inheritance: two users with 30k+ reputation say that it is inherited, and that it&#39;s not
 2.  https://stackoverflow.com/questions/2198379/are-virtual-destructors-inherited: here nothing is mentioned that would point to destructors not being inherited
 3.  https://stackoverflow.com/questions/6856488/destructors-and-inheritance-in-c: The comments seem to indicate the destructors are inherited

**Q1:** What I also know from practice, is that you cannot initialize a derived object with the same prototype than it&#39;s parent constructor without explicitely defining a constructor for the derived class, is that correct?


----------


Even though it&#39;s rather clear from the posts that destructors seem to be inherited, I&#39;m still puzzled by the fact that a user with 32k reputation would say its not. I wrote a little example that should clarify everyone&#39;s mind:

    #include &lt;cstdio&gt;

    /******************************/

    // Base class
    struct A
    {
        A() { printf( &quot;\tInstance counter = %d (ctor)\n&quot;, ++instance_counter ); }
        ~A() { printf( &quot;\tInstance counter = %d (dtor)\n&quot;, --instance_counter ); }

        static int instance_counter;
    };

    // Inherited class with default ctor/dtor
    class B : public A {};

    // Inherited class with defined ctor/dtor
    struct C : public A
    {
        C() { printf(&quot;\tC says hi!\n&quot;); }
        ~C() { printf(&quot;\tC says bye!\n&quot;); }
    };

    /******************************/

    // Initialize counter
    int A::instance_counter = 0;

    /******************************/

    // A few tests
    int main()
    {
        printf(&quot;Create A\n&quot;); A a;
        printf(&quot;Delete A\n&quot;); a.~A();

        printf(&quot;Create B\n&quot;); B b;
        printf(&quot;Delete B\n&quot;); b.~B();

        printf(&quot;Create new B stored as A*\n&quot;); A *a_ptr = new B();
        printf(&quot;Delete previous pointer\n&quot;); delete a_ptr;

        printf(&quot;Create C\n&quot;); C c;
        printf(&quot;Delete C\n&quot;); c.~C();

    }

and here is the output (compiled with g++ 4.4.3):

    Create A
        Instance counter = 1 (ctor)
    Delete A
        Instance counter = 0 (dtor)
    Create B
        Instance counter = 1 (ctor)
    Delete B
        Instance counter = 0 (dtor)
    Create new B stored as A*
        Instance counter = 1 (ctor)
    Delete previous pointer
        Instance counter = 0 (dtor)
    Create C
        Instance counter = 1 (ctor)
        C says hi!
    Delete C
        C says bye!
        Instance counter = 0 (dtor)  // We exit main() now
        C says bye! 
        Instance counter = -1 (dtor)
        Instance counter = -2 (dtor)
        Instance counter = -3 (dtor)

**Q2:** Can anybody who thinks it&#39;s not inherited please explain that?

**Q3:** So what happens when you call the constructor of a subclass with inputs? Is the &quot;empty constructor&quot; of the superclass called as well?

C++ Constructor/Destructor inheritance

Is there destructor in TypeScript? If not, how can I delete an object?
I tried `destructor()` and `~ClassName()` but it didn&#39;t work.

Is there destructor in typeScript

Is there a defined order in which local variables are deallocated in C++ (11) ?
To be more concise: In which order will side effects of the destructors of two local variables in the same scope become visible?

e.g.:

    struct X{
      ~X(){/*do something*/}
    }

    int main(){
       X x1;
       X x2;
       return 0;
    }

Is `x1` or `x2` destroyed first when main returns or is the order undefined in C++11?

C++ local variable destruction order

I use some `UserControls` which get created and destroyed within my application during runtime (by creating and closing subwindows with these controls inside).  
It&#39;s a WPF UserControl and inherits from `System.Windows.Controls.UserControl`. There is no `Dispose()` method I could override.  
`PPMM` is a `Singleton` with the same lifetime as my application.  
Now in the constructor of my (WPF) `UserControl`, I add an event handler:

	public MyControl()
	{
		InitializeComponent();

		// hook up to an event
		PPMM.FactorChanged += new ppmmEventHandler(PPMM_FactorChanged);
	}

I got used to removing such event handler in the destructor:

	~MyControl()
	{
		// hook off of the event
		PPMM.FactorChanged -= new ppmmEventHandler(PPMM_FactorChanged);
	}

Today I stumbled upon this and wondered:

**1) Is this neccessary? Or does the GC take care of it?**

**2) Does this even work? Or would I have to store the newly created `ppmmEventHandler`?**

I&#39;m looking forward to your answers.

Do you need to remove an event handler in the destructor?

Please give me some real life examples when you had to use __destruct in your classes.

Php Destructors

When I don&#39;t declare a constructor for example, the compiler will provide me with a default constructor that will have no arguments and no definition (empty body), and thus, will take **no action**.

So, if I&#39;m finished with an object for example, wouldn&#39;t the default destructor reallocate (free) memory used by the object? If it doesn&#39;t, why are we getting it?

And, maybe the same question applies to the default constructor. If it does nothing, why is it created for us by default?

Why do C++ objects have a default destructor?

Being primarily a C++ developer the absence of [RAII (Resource Acquisition Is Initialization)](http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization) in Java and .NET has always bothered me. The fact that the onus of cleaning up is moved from the class writer to its consumer (by means of `try finally` or .NET&#39;s [`using` construct](http://blogs.msdn.com/cyrusn/archive/2005/05/10/415956.aspx)) seems to be markedly inferior.

I see why in Java there is no support for RAII since all objects are located on the heap and the garbage collector inherently doesn&#39;t support deterministic destruction, but in .NET with the introduction of value-types (`struct`) we have the (seemingly) perfect candidate for RAII. A value type that&#39;s created on the stack has a well defined scope and C++ destructor semantics can be used. However the CLR does not permit a value-type to have a destructor.

My random searches found one argument that if a value-type is [boxed](http://www.csharphelp.com/archives/archive100.html) it falls under the jurisdiction of the garbage collector and therefore its destruction becomes non-deterministic. 
I feel that this argument isn&#39;t strong enough, the benefits of RAII are big enough to say that a value-type with a destructor cannot be boxed (or used as a class member).

**To cut a long story short my question is**: are there any other reasons value types can not be used in order to introduce RAII to .NET?  (or do you think my argument about RAII&#39;s obvious advantages are flawed?)

**Edit:** I must have not phrased the question clearly since the first four answers have missed the point. I *know* about `Finalize` and its non-deterministic characteristics, I know about the `using` construct and I feel these two options are inferior to RAII. `using` is one more thing the consumer of a class must remember (how many people forgot to put a `StreamReader` in a `using` block?). My question is a philosophical one about the language design, why is it the way it is and can it be improved?

For instance with a generic deterministically destructible value-type I can make the `using` and `lock` keywords redundant (achievable by library classes):

        public struct Disposer&lt;T&gt; where T : IDisposable
        {
            T val;
            public Disposer(T t) { val = t; }
            public T Value { get { return val; } }
            ~Disposer()  // Currently illegal 
            {
                if (val != default(T))
                    val.Dispose();
            }
        }
        

---

I can&#39;t help but end with a apropos quotation which I once saw but can&#39;t currently find its origin.
&gt; You can take my deterministic destruction when my cold dead hand goes out of scope.  --*Anon*


Why is there no RAII in .NET?

In C++ the following code gives a compiler error:

    void destruct1 (int * item)
    {
      item-&gt;~int();
    }

This code is nearly the same, I just typedef the int to another type and something magic happens:

    typedef int myint;
    
    void destruct2 (myint * item)
    {
      item-&gt;~myint();
    }


Why does the second code work? Does an int get a destructor just because it has been typedefed?

In case you wonder why one ever would like to do this: This comes from refactoring C++ code. We&#39;re removing the standard heap and replacing it with selfmade pools. This requires us to call placement-new and the destructors. I know that calling destructors for primitive types is useless, but we want them in the code nevertheless in case we later replace PODs with real classes.

Finding out that naked int&#39;s don&#39;t work but typedefed ones do was quite a surprise.

Btw - I have a solution that involves template-functions. We just typedef inside the template and everything is fine.


Destructors of builtin types (int, char etc..)

I am curious about the details of `__del__` in python, when and why it should be used and what it shouldn&#39;t be used for.  I&#39;ve learned the hard way that it is not really like what one would naively expected from a destructor, in that it is not the opposite of `__new__` / `__init__`.  

    class Foo(object):
    
        def __init__(self):
            self.bar = None
    
        def open(self):
            if self.bar != &#39;open&#39;:
                print &#39;opening the bar&#39;
                self.bar = &#39;open&#39;
    
        def close(self):
            if self.bar != &#39;closed&#39;:
                print &#39;closing the bar&#39;
                self.bar = &#39;close&#39;
    
        def __del__(self):
            self.close()
    
    if __name__ == &#39;__main__&#39;:
        foo = Foo()
        foo.open()
        del foo
        import gc
        gc.collect()

I saw in the documentation that it is _not_ guaranteed `__del__()` methods are called for objects that still exist when the interpreter exits.  

1. how can it be guaranteed that for any `Foo` instances existing when the interpreter exits, the bar is closed?
2. in the code snippet above does the bar get closed on `del foo` or on `gc.collect()`... or neither?  if you want finer control of those details (e.g. the bar should be closed when the object is unreferenced) what is the usual way to implement that?
3. when `__del__` is called is it guaranteed that `__init__` has already been called?  what about if the `__init__` raised?


How to force deletion of a python object?

I have an abstract class that is declared as follow:

    class my_type {
    public:
    	virtual ~my_type() = default;
    	virtual void do_something() = 0;
    };

Is it considered good practice to declare the destructor like this, with the `default` keyword? Is there a better way?

Also, is `= 0` a modern (C++11) way of specifying no default implementation, or there is a better way?

Should I default virtual destructors?

I have a class that contains a dynamically allocated array, say

    class A
    {
        int* myArray;
        A()
        {
            myArray = 0;
        }
        A(int size)
        {
            myArray = new int[size];
        }
        ~A()
        {
            // Note that as per MikeB&#39;s helpful style critique, no need to check against 0.
            delete [] myArray;
        }
    }

But now I want to create a dynamically allocated array of these classes. Here&#39;s my current code:

    A* arrayOfAs = new A[5];
    for (int i = 0; i &lt; 5; ++i)
    {
        arrayOfAs[i] = A(3);
    }

But this blows up terribly. Because the new `A` object created (with the `A(3)` call) gets destructed when the `for` loop iteration finishes, and this means that the internal `myArray` of that `A` instance gets `delete []`-ed.

So I think my syntax must be terribly wrong? I guess there are a few fixes that seem like overkill, which I&#39;m hoping to avoid:

 * Creating a copy constructor for `A`.
 * Using `vector&lt;int&gt;` and `vector&lt;A&gt;` so I don&#39;t have to worry about all this.
 * Instead of having `arrayOfAs` be an array of `A` objects, have it be an array of `A*` pointers.

I would think this is just some beginners thing where there&#39;s a syntax that actually works when attempting to dynamically allocate an array of things that have internal dynamic allocation.

(Also, style critiques appreciated, since it&#39;s been a while since I did C++.)

**Update for future viewers**: All of the answers below are really helpful. Martin&#39;s is accepted because of the example code and the useful &quot;rule of 4,&quot; but I really suggest reading them all. Some are good, succinct statements of what&#39;s wrong, and some point out correctly how and why `vector`s are a good way to go.


Dynamically allocating an array of objects

Can the default destructor be generated as a virtual destructor automatically?

If I define a base class but no default destructor, is there a default virtual destructor
generated automatically?

Can the default destructor be generated as a virtual destructor automatically?

From my example program, it looks like it does call the destructors in both the cases. At what point does it call the destructors for global and class-static variables since they should be allocated in the data section of the program stack?

Does C++ call destructors for global and class static variables?

    class MyDestructableClass {
       function __construct() {
           print &quot;\nIn constructor\n&quot;;
           $this-&gt;name = &quot;MyDestructableClass&quot;;
       }
    
       function __destruct() {
           print &quot;\nDestroying &quot; . $this-&gt;name . &quot;\n&quot;;
       }
    }
    
    $obj = new MyDestructableClass();


When the above script is in a **complex** environment,the `__destruct` won&#39;t get called when `exit`,but I can&#39;t reproduce it easily.Have someone ever noticed this ?

**EDIT**

I&#39;ll post the whole stuff here,it&#39;s the testing environment of symfony,which means you can easily reproduce it if you are familar with the framework:

    require_once dirname(__FILE__).&#39;/../bootstrap/Doctrine.php&#39;;
     
    
    $profiler = new Doctrine_Connection_Profiler();
    
    $conn = Doctrine_Manager::connection();
    $conn-&gt;setListener($profiler);
    
    $t = new lime_test(0, new lime_output_color());
    
    class MyDestructableClass {
       function __construct() {
           print &quot;\nIn constructor\n&quot;;
           $this-&gt;name = &quot;MyDestructableClass&quot;;
       }
    
       function __destruct() {
           print &quot;\nDestroying &quot; . $this-&gt;name . &quot;\n&quot;;
       }
    }
    
    $obj = new MyDestructableClass();
    $news = new News();
    
    $news-&gt;setUrl(&#39;http://test&#39;);
    $news-&gt;setHash(&#39;http://test&#39;);
    $news-&gt;setTitle(&#39;http://test&#39;);
    $news-&gt;setSummarize(&#39;http://test&#39;);
    $news-&gt;setAccountId(1);
    $news-&gt;setCategoryId(1);
    $news-&gt;setThumbnail(&#39;http://test&#39;);
    $news-&gt;setCreatedAt(date(&#39;Y-m-d H:i:s&#39;,time()));
    $news-&gt;setUpdatedAt(date(&#39;Y-m-d H:i:s&#39;,time()));
    $news-&gt;save();
    exit();

When will __destruct not be called in PHP?

In my destructor I want to destroy a thread cleanly.

My goal is to wait for a thread to finish executing and THEN destroy the thread.

The only thing I found about querying the state of a pthread is [pthread_attr_setdetachstate][1] but this only tells you if your thread is:

 - PTHREAD_CREATE_DETACHED 
 - PTHREAD_CREATE_JOINABLE

Both of those have nothing to do with whether the thread is still running or not.

**How do you query a pthread to see if it is still running?**

  [1]: https://computing.llnl.gov/tutorials/pthreads/man/pthread_attr_getdetachstate.txt

How do you query a pthread to see if it is still running?

C++20 introduced &quot;destroying [`operator delete`](https://en.cppreference.com/w/cpp/memory/new/operator_delete)&quot;: new overloads of `operator delete` that take a tag-type [`std::destroying_delete_t`](https://en.cppreference.com/w/cpp/memory/new/destroying_delete_t) parameter.

What exactly is this and when is it useful?

What is &quot;destroying operator delete&quot; in C++20?

I expected `A::~A()` to be called in this program, but it isn&#39;t:

    #include &lt;iostream&gt;
    
    struct A {
      ~A() { std::cout &lt;&lt; &quot;~A()&quot; &lt;&lt; std::endl; }
    };
    
    void f() {
      A a;
      throw &quot;spam&quot;;
    }
    
    int main() { f(); }

However, if I change last line to 

    int main() try { f(); } catch (...) { throw; }

then `A::~A()` *is* called.

I am compiling with &quot;Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86&quot; from Visual Studio 2005. Command line is `cl /EHa my.cpp`.

Is compiler right as usual? What does standard say on this matter?

Why destructor is not called on exception?

What is the order in which the destructors and the constructors are called in C++? Using the examples of some Base classes and Derived Classes

What is the order in which the destructors and the constructors are called in C++

Does Qt automatically remove connections between objects , when one of the side is deleted ?

e.g `connect (A .. , B ..)` , when A (a pointer) is deleted , or B is deleted , will the connection be disconnected ? 

Is it necessary to use disconnect explicitly in destructor ?

Are signals in Qt automatically disconnected when one of the class is deleted

Consider the following code:

    void foo()
    {
        {
            CSomeClass bar;
     
            // Some code here...
    
            goto label;
            
            // and here...
        }
    
    label:
        // and here...
    }
    
Will the destructor of bar be called ?

Goto out of a block: do destructors get called?

The more we use RAII in C++, the more we find ourselves with destructors that do non-trivial deallocation. Now, deallocation (finalization, however you want to call it) can fail, in which case exceptions are really the only way to let anybody upstairs know of our deallocation problem. But then again, throwing-destructors are a bad idea because of the possibility of exceptions being thrown during stack unwinding. `std::uncaught_exception()` lets you know when that happens, but not much more, so aside from letting you log a message before termination there&#39;s not much you can do, unless you&#39;re willing to leave your program in an undefined state, where some stuff is deallocated/finalized and some not.

One approach is to have no-throw destructors. But in many cases that just hides a real error. Our destructor might, for example, be closing some RAII-managed DB connections as a result of some exception being thrown, and those DB connections might fail to close. This doesn&#39;t necessarily mean we&#39;re ok with the program terminating at this point. On the other hand, logging and tracing these errors isn&#39;t really a solution for every case; otherwise we would have had no need for exceptions to begin with. 
With no-throw destructors we also find ourselves having to create &quot;reset()&quot; functions that are supposed to be called before destruction - but that just defeats the whole purpose of RAII.

Another approach is just to [let the program terminate][1], as it&#39;s the most predictable thing you can do.

Some people suggest chaining exceptions, so that more than one error can be handled at a time. But I honestly never actually seen that done in C++ and I&#39;ve no idea how to implement such a thing.

So it&#39;s either RAII or exceptions. Isn&#39;t it? I&#39;m leaning toward no-throw destructors; mainly because it keeps things simple(r). But I really hope there&#39;s a better solution, because, as I said, the more we use RAII, the more we find ourselves using dtors that do non-trivial things.

**Appendix**

I&#39;m adding links to interesting on-topic articles and discussions I&#39;ve found:

  - [Throwing Destructors][2]
  - StackOverflow discussion on the [problems with SEH][3]
  - StackOverflow discussion on [throwing-destructors][4] (thanks, Martin York)
  - [Joel on Exceptions][5]
  - [SEH Considered Harmful][6] 
  - [CLR Exception Handling][7] which also touches on exception chaining
  - [Herb Sutter on std::uncaught_exception][8] and why it&#39;s not as useful as you think
  - [Historical discussion][9] on the matter with interesting participants (long!)
  - Stroustrup explaining [RAII][10]
  - Andrei Alexandrescu&#39;s [Scope Guard][11]


  [1]: http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml
  [2]: http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml
  [3]: https://stackoverflow.com/questions/164372/is-there-a-good-way-around-the-problems-of-structured-exception-handling-try-ex
  [4]: https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor#130123
  [5]: http://www.joelonsoftware.com/items/2003/10/13.html
  [6]: http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx
  [7]: http://bartdesmet.net/blogs/bart/archive/2006/04/04/clr-exception-handling-from-a-to-z-everything-you-didn-t-want-to-know-about-try-catch-finally-fault-filter.aspx
  [8]: http://www.gotw.ca/gotw/047.htm
  [9]: http://www.cpptalk.net/1-vt12438.html?postdays=0&amp;postorder=asc&amp;start=0
  [10]: http://www.research.att.com/~bs/bs_faq2.html#finally
  [11]: http://www.ddj.com/cpp/184403758

RAII vs. exceptions

Is this program well-defined, and if not, why exactly?

    #include &lt;iostream&gt;
    #include &lt;new&gt;
    struct X {
        int cnt;
        X (int i) : cnt(i) {}
        ~X() {  
                std::cout &lt;&lt; &quot;destructor called, cnt=&quot; &lt;&lt; cnt &lt;&lt; std::endl;
                if ( cnt-- &gt; 0 )
                    this-&gt;X::~X(); // explicit recursive call to dtor
        }
    };
    int main()
    {   
        char* buf = new char[sizeof(X)];
        X* p = new(buf) X(7);
        p-&gt;X::~X();  // explicit call to dtor
        delete[] buf;
    }

My reasoning: although [invoking a destructor twice is undefined behavior][1], per 12.4/14, what it says exactly is this:
&gt; the behavior is undefined if the
&gt; destructor is invoked for an object
&gt; whose lifetime has ended

Which does not seem to prohibit recursive calls. While the destructor for an object is executing, the object&#39;s lifetime has not yet ended, thus it&#39;s not UB to invoke the destructor again. On the other hand, 12.4/6 says:
&gt; After executing the body [...] a
&gt; destructor for class X calls the
&gt; destructors for X&#39;s direct members,
&gt; the destructors for X&#39;s direct base
&gt; classes [...]

which means that after the return from a recursive invocation of a destructor, all member and base class destructors will have been called, and calling them again when returning to the previous level of recursion would be UB. Therefore, a class with no base and only POD members can have a recursive destructor without UB. Am I right?

  [1]: https://stackoverflow.com/questions/2771567/why-exactly-is-calling-the-destructor-for-the-second-time-undefined-behavior-in-c


Can a destructor be recursive?

Consider the following class:

    struct S { ~S() = delete; };

Shortly and for the purpose of the question: I cannot create instances of `S` like `S s{};` for I could not destroy them.  
As mentioned in the comments, I can still create an instance by doing `S *s = new S;`, but I cannot delete it as well.  
Therefore, the only use I can see for a deleted destructor is something like this:

    struct S {
        ~S() = delete;
        static void f() { }
    };

    int main() {
        S::f();
    }

That is, define a class that exposes only a bunch of static functions and forbid any attempt to create an instance of that class.

What are the other uses (if any) of a deleted destructor?

Uses of destructor = delete;

As far as I know, I should destroy in destructors everything I created with `new` and close opened filestreams and other streams.
However, I have some doubts about other objects in C++:

- `std::vector` and `std::string`s: Are they destroyed automatically?

- If I have something like

        std::vector&lt;myClass*&gt; 

  of pointers to classes. What happens when the vector destructor is called?  
  Would it call automatically the destructor of `myClass`? Or only the vector is destroyed but all the Objects it contains are still existant in the memory?

- What happens if I have a pointer to another class inside a class, say:

        class A {
          ClassB* B;
        }

  and Class A is destroyed at some point in the code. Will Class B be destroyed too or just the pointer and class B will be still existent somewhere in the memory? 

C++ Destructors with Vectors, Pointers,

In my C++11 code I get the clang warning &quot;Declaration requires an exit-time destructor&quot; in the following case:

    static const std::map&lt;int, const someStruct&gt; mymap = {
        {1, {
            &quot;A&quot;,
            &quot;B&quot;,
            &quot;C&quot;
        }},
        {2, {
            &quot;D&quot;,
            &quot;E&quot;,
            &quot;F&quot;
        }}
    };

As far as I understand Google an &quot;exit-time destructor&quot; is required to destroy main() and statics in a deterministic way to prevent crashes on exit due to &quot;already released variables&quot;. Is that right? Can someone explain it better?

Plus: What can I do about it (I don&#39;t want to disable the warning)? The code above is used within context of one thread only.

Looks like this is the way Chromium deals with these cases; would that be the right way for my case as well?

    #define CR_DEFINE_STATIC_LOCAL(type, name, arguments) \
      static type&amp; name = *new type arguments

(Source: https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/base/basictypes.h)

All Destructor Solutions on Gang of Coders

Total of 49 Destructor Solutions