Must I always use a deconstructor?

Like the title suggests, for OOP, do I need to define a deconstructor all the time?

Or do I just not type it at all, will it have a default deconstructor, like the default constructor?

A default one is provided, but there might be reasons why you'd need to make your own.

Your questions are good, but I think at this point, you'd be better off reading the tutorials and FAQs on this site and asking questions when you run into trouble.

http://www.cprogramming.com/tutorial.html

Only if it's needed:

Code:

---

class thing
{
private:
    char *t;
   
public:
    thing( void )
    {
        t = new char[100];
    }
};


int main( void )
{       
    { // thing created
        thing kfsd;
    } // thing destroyed


        return 0;
}

---

Here memory is allocated, but it's not destroyed, so you need a destructor there:

Code:

---

class thing
{
private:
    char *t;
   
public:
    thing( void )
    {
        t = new char[100];
    }
    ~thing( void )
    {
        delete []t;
    }
};


int main( void )
{       
    { // thing created
        thing kfsd;
    } // thing destroyed


        return 0;
}

---

Like so. But if you don't allocate memory using new (or some C functions), you don't need to delete it afterwards, so you don't need a destructor.

Hey, thanks everyone :)

twomers: Hmm, so does that mean if I define a deconstructor to free whatever memory I've allocated for that object, I won't have to specifically free (delete) the object before the program ends? It'll be done automatically when I exit the program?

And thanks MacGyver for pointing me in the right direction :)

Edit: Oh and sorry for so many basic questions. I have an urgent job of translating Java to C++ and I don't have much time to search here and there :/

>> deconstructor
"destructor" not "deconstructor"

>> does that mean if I define a deconstructor to free whatever memory I've allocated for that object, I won't have to specifically free (delete) the object before the program ends? It'll be done automatically when I exit the program?

No. Any memory you allocate with new, you have to deallocate with delete. If you create an object locally (like kfsd in twomers code), then you don't have to do anything it will be destroyed on its own. Since it is a class, its destructor will be called automatically. However, if it has its own data that it allocated with new, you have to make sure that gets cleaned up in the class destructor.

Or to put some code to Daved's words:

Code:

---

class thing
{
private:
    char *t;
   
public:
    thing( void )
    {
        t = new char[100];
    }
    ~thing( void )
    {
        delete []t;
    }
};

int main( void )
{
    thing *kjldsf = new thing[100];
    // this NEEDS to be deleted.

    delete []kjldsf;

    return 0;
}

---

Everything inside each of the elements will get deleted with the destructor, but since the pointer kjldsf (sorry for the bad name, I couldn't think of anything so I slammed my face on the keyboard), has memory dynamically allocated to it outside of the scope of the class this needs to be deleted outside of it, ie in main.

Rule_Of_Three

Also note that in modern C++ you don't use the destructor as often as you'd think. For example, you don't actually create arrays like in twomers example code, you use the vector class instead (or some other suitable container). The vector class cleans up after itself automatically (with its own destructor) and so you don't have to write a destructor for a class that uses it. The default destructor will call vector's destructor automatically and it will be cleaned up for you.

A bit more on that.
Whenever you need a destructor you also need to define a copy constructor and an assignement operator. If you want that the object is not copyable or assignable, make them private.
The default implementations that the compiler generates will get you in trouble.
Like in the examples from twomers. The destructor of a copy would delete t as well resulting in double delete of the same memory.
Kurt

Just to point out, if you allocate memory with new in the constructor then delete it with the destructor, to be safe NULL the pointer to be absolutley sure the memory is deleted

Code:

---

foo::~foo()
{
  delete myInt;
  myInt = NULL;
}

---

This is not essential. I belive there will be a new operartor called NULLPtr or somthing with the new standard. Not 100% sure on this though.

Quote:

---

Just to point out, if you allocate memory with new in the constructor then delete it with the destructor, to be safe NULL the pointer to be absolutley sure the memory is deleted

---

I had the impression is that the delete/delete[] was the one that results in deallocation of memory, and zeroing the pointer is just to be safe, as a second delete/delete[] would then be effectively a no-op, plus you can check to see if the pointer is null if you want to be certain before dereferencing it.

>> to be safe NULL the pointer to be absolutley sure the memory is deleted.
There is really no reason to do this in a destructor. Apparently some extremely old compilers had a bug where not doing so would cause a crash, but if your compiler has that bug you should change compilers rather than worry about it.

I never heard of that before.

So, you could change the destructor I posted earlier to:

Code:

---

~thing( void )
{
    if( t )
        delete []t;

    //Should this be within the if?
    t = NULL;
}

---

One question is commented. Should the t be within the scope of the if statement? Or does it matter?

Code:

---

~thing( void )
{
    delete [] t;
}

---

That's how you should do it, the rest is completely unnecessary clutter.

That's what I thought. Thought for a sec that I would have to rewrite some things.

I never understood that set a deleted object pointer to 0 advice. But I'm shure it doesn't make any sense to do that in a destructor. If you delete an object that holds a pointer to another object then this object is gone. If you delete that same object again then to protect from deleting the contained object is too late.
Kurt

Quote:

---

I never understood that set a deleted object pointer to 0 advice.

---

You can read:
Why doesn't delete zero out its operand?

From that link

Code:

---

        T* p = new T;
        T* q = p;
        delete p;
        p = 0;          // I added this
        delete q;        // ouch!

---

That's why I never thought it makes much sense.
Kurt

Quote:

---

That's why I never thought it makes much sense.

---

What Stroustrup meant is that zeroing a pointer does not guarantee that there cannot be an attempt to deallocate memory that has already been deallocated. It still is good practice since it does prevent the case where such an attempt is made with the same pointer, though rather useless in swgh's example in my opinion, since there is no way to use delete/delete[] on the same pointer.

Quote:

---

Originally Posted by laserlight

What Stroustrup meant is that zeroing a pointer does not guarantee that there cannot be an attempt to deallocate memory that has already been deallocated. It still is good practice since it does prevent the case where such an attempt is made with the same pointer, though rather useless in swgh's example in my opinion, since there is no way to use delete/delete[] on the same pointer.

---

We do agree. Don't we.
Kurt

Lol I did not mean for everybody to jump on my back and attack what I stated. I was only suggesting it as I was taught this in colege, and I normally do that when allocating memory with new. But if it is wrong, then I shall just tell the desructor to delete rhe memory and avoid the NULL operation. Odd no compiler warned me about this though. Thanks for the advice on the bad advice my tutor told me once guys ;)

I believe the rule was that the compiler would write a constructor, destructor, copy constructor, and assignment operator if and only if you did not write any one of those yourself. Which boils down totreating classes like structs, but you are still limited by the fact that you shouldn't use pointers as members of such a construct:

Code:

---

class mouse {
  public:
  double height;
  double kilos;
  enum COLOR fur;
  char *name;
};

---

What have you. Unfortunately, since you opted to give your pet mouse a name, mice can't be copied correctly. The compiler only writes a copy constructor that does *new = *old; leaking the old memory.

So, do you have to provide a constructor and destructor? Almost always. And some other stuff too.

>> I did not mean for everybody to jump on my back and attack what I stated.
Nobody's attacking, just clarifying your statement and later questions.

>> Odd no compiler warned me about this though.
Technically it could be useful if the pointer was not a member or if a derived class is deleting a base class member pointer, but those situations are very rare and have specific reasons why you would need to do that.

>> I believe the rule was that the compiler would write a constructor, destructor, copy constructor, and assignment operator if and only if you did not write any one of those yourself.

Each is separate. If you don't write a constructor, a default constructor will be created for you. If you don't write a destructor, a default destructor will be created for you. Same for assignment operator and the same for copy constructor.