🔒 Locked
deleting pointers
Advertisement
Original Post
I have a global variable: Player *player1 = new Player(0,0,0,100); //don't worry about the parameters Of course, while my program is running, I never want this object deleted (because there will always be a player1). But before my program terminates, should I delete player1 or does C++ do that for me when the program is terminated?
Quote:
Original post by bballmitch
I have a global variable:
Player *player1 = new Player(0,0,0,100); //don't worry about the parameters
Of course, while my program is running, I never want this object deleted (because there will always be a player1). But before my program terminates, should I delete player1 or does C++ do that for me when the program is terminated?
whenever you allocate memory using new you have to delete it yourself. consider allocating it on the stack or using std::auto_ptr or one of the smart pointers in the boost library.
No, You should always delete it yourself.
Where? It depends on your platform/api.
For example:
-using w32 standard api you will get communicate wm_destroy. Thats your plase for deleting such pointers:)
-In MFC just place it in destructor.
-Using standard console build place your destroy somewhere near "return" in main function.
What is your platform????
Where? It depends on your platform/api.
For example:
-using w32 standard api you will get communicate wm_destroy. Thats your plase for deleting such pointers:)
-In MFC just place it in destructor.
-Using standard console build place your destroy somewhere near "return" in main function.
What is your platform????
If you're asking 'is any memory I leak reclaimed by the OS when my program exits' then the answer is yes. If you don't delete the player before you leave the program, you don't 'lose' memory; But it's destructor will never be run.
Other resources aren't reclaimed. Windows won't return handles; you have to explicitly CloseHandle them, and most OS's will leak 'file handles' if you open a file and don't close it.
Other resources aren't reclaimed. Windows won't return handles; you have to explicitly CloseHandle them, and most OS's will leak 'file handles' if you open a file and don't close it.
Quote:
Original post by Deyja
If you're asking 'is any memory I leak reclaimed by the OS when my program exits' then the answer is yes. If you don't delete the player before you leave the program, you don't 'lose' memory; But it's destructor will never be run.
Other resources aren't reclaimed. Windows won't return handles; you have to explicitly CloseHandle them, and most OS's will leak 'file handles' if you open a file and don't close it.
Yes, that was my question. Can you elaborate on your second paragraph? I'm not sure I know how not closing a handel will effect my computer. Are there any other resources that aren't reclaimed?
Quote:
Original post by bballmitch
Yes, that was my question. Can you elaborate on your second paragraph? I'm not sure I know how not closing a handel will effect my computer. Are there any other resources that aren't reclaimed?
Reserving the right to be utterly wrong, I believe that not closing a file handle will result in you not being able to edit that particular file until the handle has been closed.
I'm sure you've probably experienced it with either your own or other's software :)
Edit: typo
Actually, most OSs will close all handles for a process when it exits, but older OSs (Win9x in particular) have a habit of not doing this. There can also be other problems such as data not getting flushed from buffers to disk if the OS has to close the handle for you.
Generally, assume the OS won't free anything for you, and you should free it yourself. That applies to memory allocated with new or OS specific functions like VirtualAlloc, GlocalAlloc, etc, handles (File handles, mutexes, thread handles, etc), and anything that the OS gives you that has a way to close or delete the resource.
Generally, assume the OS won't free anything for you, and you should free it yourself. That applies to memory allocated with new or OS specific functions like VirtualAlloc, GlocalAlloc, etc, handles (File handles, mutexes, thread handles, etc), and anything that the OS gives you that has a way to close or delete the resource.
Handles I can understand, but I have no idea how Windows/your OS would fail to reclaim memory allocated by VirtualAlloc.
Quote:It'll always manage to reclaim the memory, but you shouldn't rely on it, just in case there's a buggy version of Windows that doesn't, and just as a matter of good practice.
Original post by DaBookshah
Handles I can understand, but I have no idea how Windows/your OS would fail to reclaim memory allocated by VirtualAlloc.
The heap is allocated by OS functions, so any memory allocated in it (with malloc, new, etc) will be freed when the program exits. The main problem is when you have memory leaks when the program is running, and then you end up allocating more and more memory, and then you end up causing the OS to page memory like crazy just to get it to your program.
Why do you even allocate it with new? Couldn't you just have a "static Player player1(0,0,0,100)"?
You shouldn't depend on anyone else than yourself cleaning up your mess. Most modern OS reclaim most resources, but this is not a guarentee. Also the destructor will not be called which could give you some problems if the destructor for example wrote log files.
You shouldn't depend on anyone else than yourself cleaning up your mess. Most modern OS reclaim most resources, but this is not a guarentee. Also the destructor will not be called which could give you some problems if the destructor for example wrote log files.
Quote:
Original post by DaBookshah
Handles I can understand, but I have no idea how Windows/your OS would fail to reclaim memory allocated by VirtualAlloc.
Bugs, old/crappy OS'es. (Win95 had some problems with this, although I don't know exactly what it did and didn't do, it was pretty clear to see that memory didn't always get freed the way it was supposed to when an app crashed)
Even if you ignore the bugs, there's no guarantee an OS will even attempt to reclaim the memory. Of course, any serious OS will do so, but they don't *have* to, and you shouldn't rely on it.
It's like when you go to the movies, and have popcorn, candy, soda or whatever. Then at the end of the movie, you either clean up after yourself and throw your garbage in the bin, or you leave it for someone else to clean up.
Now there may or may not be any cleaners working that day, so you don't know if that gets cleaned up or if it will eventually pile up until they have to close the cinemas for intensive clean up.
Also if you clean it up yourself you might notice there is some candy left and decide to bring that with you, whilst leaving it behind dispossess you of that option.
Now there may or may not be any cleaners working that day, so you don't know if that gets cleaned up or if it will eventually pile up until they have to close the cinemas for intensive clean up.
Also if you clean it up yourself you might notice there is some candy left and decide to bring that with you, whilst leaving it behind dispossess you of that option.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement