I was coding the part of my game were it deletes all the bitmaps when the game ends, and I thought, "Why am I supposed to do this". So What's the reason?
Printable View
I was coding the part of my game were it deletes all the bitmaps when the game ends, and I thought, "Why am I supposed to do this". So What's the reason?
In order to free up the memory allocated by those objects.
When the game ends? Usually nothing: usually the operating system will clean it for you. But it is bad habbit to start relying on it, especially if you move to a system that doesn't do that in the future. Also, future edits in the code might become fairly confusing: imagine someone decides to add something else at the end, not realising so much memory is still in use.
Just destroy *anything* when you no longer need it (unless you cache it for later).
Ok thanks.
Well, just to make sure you understand.
In the c/c++ programming languages, if you create (allocate) an object with the new operator, and you do not destroy (de allocate) the object with the delete operator, then you will have whats called a memory leak.
When you use the new operator, your program is asking the OS for a specific amount of memory, when you call the delete operator, you are telling the OS that you are finished with the memory. If you never tell the OS you are done with the memory, then the OS assumes the memory is still is use --thus creating a memory leak.
So, what ends up happening is that after you close your program, you may notice that you don't have as much available ram as you would think because the OS is reporting that it is still in use by a program.
On Windows, when the current process terminates, all the memory allocated for that process is being freed. But just as many other said, by not explicitly freeing memory you are probably creating a memory leak bug when your code might be used in another way.
It's worth noting that the newer languages don't require you to explicitly free/delete things, instead their runtime has a thread that sits in the background, makes a note of your allocations and periodically frees it in one go (garbage collection).
Just a different paradigm, but bear in mind that the thread might decide to do this when your code needs more memory and will hold your code up.
I prefer the manual approach.
....as do I....and I suspect the majority of the members here would share that sentiment.Quote:
I prefer the manual approach.
On the Windows platform, in c/c++ if you allocate memory with the new, and DO NOT release it with a delete, the memory WILL NOT BE FREED with the program terminates.
Please, read up, http://en.wikipedia.org/wiki/Memory_leak
It will be freed when the application exits. Runtime leaks will not be fixed if the program does not exit so if a runtime leak is left unchecked and your app is allowed to run then your program will eventually crash.
C++ also has RAII to free memory, eg: smart pointers.Quote:
Originally Posted by SMurf
Set them, forget them, so to speak. Only be sure to choose the proper smart pointer.
This is the preferred way in modern C++, though I don't know if this is the method you "prefer." Though I certainly prefer it. What I do hate is garbage collection, though. It has no business in apps.
Personal opinions aside, with a question like "why is it important to delete objects?" the principle answer is because C++ does not have garbage collection built in. So avoiding mention of garbage collection would mean avoiding the answer IMHO.
I still fail to understand your modern and non-modern approach to C++. Most of us are not that exclusive when it comes to modern or non-modern. The pure and simple point of this particular thread and of C++ is....clean up your own garbage. Whether you do that through your own means or some other means as long as the job gets done that is all we care about.Quote:
modern C++,
The how is more about implementation specific choices than about fundamental memory management concepts. Smart pointers, while nice, are not the only way or the correct way in every case to do memory management. They are one very nice way but what they provide can be done manually if one would choose to go that route. Again it depends on the requirements of the application.
When I say modern C++, I naturally refer to idoms and techniques typically used today. If you're writing a GUI application, there is a 99% chance you're using a smart pointer if you're using dynamic memory.
Of course you're right in that smart pointers are not always the right tool. That is why we have a choice, after all.
But technically, I wouldn't call it a burden anymore. we set a smart pointer and we forget it. The only important thing is the design. We cannot escape that we must plan the use of a proper smart pointer.
Also note preferred. There are many things that are preferred, and sometimes you just have to go against those principles in order to meet the goal of the project. And that is fine, so long as it is justified.
In the end, you are free to what you want, but I just wanted to point out that that there are practices and idoms in C++ today, and one of them is to use a smart pointer, when applicable.
This is too broad of a statement to be true.Quote:
If you're writing a GUI application, there is a 99% chance you're using a smart pointer if you're using dynamic memory.