Must I always use a deconstructor?

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

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

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.

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.