Spotting memory leaks

[DaveMortimer]

Hello All.

A few weeks ago I threw out my C++ IDE's (KDevelop and MSVC++) and started using qmake with my own elementary project files so that I could better understand the build process. The only thing I miss about the IDE's is the facility which spots memory leaks.

I am using Qt and have been writing release versions. Inevitably, I have had a few crashes due to bad memory access attempts, but I have been able to easily fix these. However, I am not sure whether my programs are actually leaving memory leaks.

I know how to use 'new' and 'delete', but I am still working blind. I have a couple of questions...

----------------------------------------------
(1)
I currently write the destructors of any objects that I instantiate with 'new' as follows...

AClass::~AClass()
{
  if( DeleteFlag )
  {
    delete this;
  }
}

...where DeleteFlag is a bool that is initialised to 1 when the object is created. If the object needs to be deleted before the application closes down, I set DeleteFlag to zero, and I also set the pointer to zero.

----------------------------------------------
(2)
If the application process crashes, what happens to the borrowed memory?

(a) Does the OS call the destructor to reclaim the memory?
(b) Will the OS clean up without calling the destructor?
(c) Other...what?

----------------------------------------------
(3)
Is there an OS facility (perhaps in control panel somewhere) which will tell me whether there are any memory leaks?

----------------------------------------------
(4)
If you think I am doing things wrong, or you have a better 'failsafe' way of ensuring that my programs do not leave memory leaks, can you please let me know?

----------------------------------------------

Thanks very much all,

Dave

[helios]

1. I'm pretty sure this is infinite recursion waiting to happen.
2. B. The segment belonging to the program is freed by the OS. No program code is executed. This is at least true for the NT and the Linux kernels.
3. No, but there are memory debuggers available to do just that.
4. There's no foolproof method other than being careful or not using dynamic memory allocation.

EDIT: What exactly are you trying to do with that destructor? Deleting 'this' could under no circumstance lead to anything good. A destructor is only supposed to free the memory of dynamically allocated objects and arrays that the object owns (e.g. it doesn't free them if they are supposed to be freed by someone else).
Example:

struct A{
	char *array;
	char *array2;
	Object obj;
	Object *obj2;
	A(char *a){
		this->array=new char[50];
		this->array2=a;
		this->obj2=new Object;
	}
	~A(){
		delete[] this->array;
		delete this->obj2;
	}
};

[firedraco]

In response to 1, yes it is, I created a test class with a destructor that deletes itself, and it recursed a very long time and eventually it hit a segfault (or something similar).

[DaveMortimer]

Thank you very much for your time helios.

I had a surf around the web for a couple of hours and read a couple of articles. While there seems to be some debate about whether using 'delete this' is good or bad practice (some people use it successfully), I agree with you that an object should be deleted by its creator's destructor (providing the object is not being used elsewhere of course) simply because it is always best to keep things as simple as possible. The destructor I wrote was flawed in that it did not have a stopping condition (a golden rule of recursion).

Thanks to you too firedraco.

All the best,

Dave