Why do we need to free memory?
So I'm working with SDL2 and being a good little programmer I make sure to delete any pointers, windows (
My question is why do we do this? Will the OS really hold onto them after they close program if we don't delete them before closing? Could you really crash a computer by running and closing a program over and over again that doesn't free it's allocated memory?
Like I said I always make sure to free this stuff up to maintain good programming habits but I still have this mindset that the OS will just go "oh that program is closed" and basically forget everything related to it and the memory will be freed up.
SDL_DestroyWindow), and textures (SDL_DestroyTexture) that I created and used during the programs.My question is why do we do this? Will the OS really hold onto them after they close program if we don't delete them before closing? Could you really crash a computer by running and closing a program over and over again that doesn't free it's allocated memory?
Like I said I always make sure to free this stuff up to maintain good programming habits but I still have this mindset that the OS will just go "oh that program is closed" and basically forget everything related to it and the memory will be freed up.
Last edited on
| Will the OS really hold onto them after they close program if we don't delete them before closing? |
No. The OS hands out memory to a process, and when the process ends, takes it all back again. Shouldn't matter what the process did with that memory or what state it left things in. The OS takes it back.
A principal problem with never freeing memory is running out of memory. If you never free the memory, but have a program running a long time, always creating new objects, you consume more and more and more until eventually you use all the memory easily available, and the OS either has to start using the hard drive as spare memory (and your program slows down and may become so slow it's unusable, and other programs also become painfully slow because they can't get any memory either, and chunks of their working memory has suddenly been moved to a hard drive, and the OS seems to even freeze if you're unlucky) or the OS might simply decide your program is out of control and kills it stone cold dead without warning.
Associated with this is the problem of finding these memory leaks (a "memory leak" is the term used to describe memory that you have lost the pointer to and thus cannot delete, even if you wanted to). There are tools that can help you find memory leaks. If your code is full of little memory leaks that you don't care about, maybe because they're not recurring so you as programmer know they won't expand massively, you will have a lot of noise to look through before you find the really troublesome memory leaks.
It's not uncommon for many programs to not tidy up their memory fully when they close. It's often harmless. Nonetheless, it is good practice to tidy up your memory, even if only because it forces you to actually think about everything you allocate and design sensibly.
The OS will take care of it for you when the program closes, but as I said above, that might be because the OS has decided to close your out-of-control program for you, without warning.
That's a good question. Like you said, in fact, the OS will free the program's memory after it is closed. However, without explicitly delete pointers in the program, their destructors will not be called.
I understand the need for freeing up the memory of say a "dead" enemy or "destroyed" game object because the game is still running and there is no sense in storing memory of an entity that is no longer in the game, but I just can't wrap my head around freeing the memory of the SDL_Window or SDL_Rendere upon quitting/exiting the application. If it's for no other reason than like you said, good practice, then I can accept that. But if there is some other reason why all these tutorials want me to free the memory of the window that is being closed anyways, then I guess I'm missing it.
If I were writing a tutorial, it would by definition be for someone who was inexperienced.
I could definitely see myself deciding that rather than push onto them the cognitive load of understanding when it's "safe" to be lazy and not bother tidying up memory (which is the discussion we've just had), in a tutorial that's not even about memory safety, and when it's dangerous, I would simply go with the safest, easy to understand option that teaches good habits; always tidy up. Simple, safe, clear, correct.
Be aware also that in this specific case, you don't know what's happening inside those functions,
I could definitely see myself deciding that rather than push onto them the cognitive load of understanding when it's "safe" to be lazy and not bother tidying up memory (which is the discussion we've just had), in a tutorial that's not even about memory safety, and when it's dangerous, I would simply go with the safest, easy to understand option that teaches good habits; always tidy up. Simple, safe, clear, correct.
Be aware also that in this specific case, you don't know what's happening inside those functions,
SDL_DestroyWindow and so on. Are they doing no more than deleting some pointers? Is that it? You don't know for sure. They could be doing something useful or important. If the API says you should call them at the end, you should, because you don't know what they're doing. The whole point of having an API is to use code someone else wrote for you without having to understand how it works, and when you don't know how something works, not following the instructions is a bad idea. If they really were just a simple delete, then sure, maybe you could use your extra knowledge as programmer that the program is ending, and you can get away with being lazy, but have you dug through all the code to check?
Last edited on
@Moschops appreciate the reply. Please don't get the idea that I'm trying to rebel and say I do or don't need to do what the API says. Trust me, I'm following it to the T. I'm also quite OCD in life as not cleaning up my pointers and freeing my memory is something I just can't NOT do, heh. I just simply wanted to know what logic there was to freeing up something that would be freed up by the OS regardless in just milliseconds later, had I not manually freed it up.
I'll continue to practice good habits as I usually try to do and free these things up just before exiting the program. I just wanted to try and get a better understanding of the logic and reasoning behind it all. Informative reply and you're right, I have not looked into the code as to what SDL_DestroyWindow and the other memory freeing functions of SDL do.
I'll continue to practice good habits as I usually try to do and free these things up just before exiting the program. I just wanted to try and get a better understanding of the logic and reasoning behind it all. Informative reply and you're right, I have not looked into the code as to what SDL_DestroyWindow and the other memory freeing functions of SDL do.
Since we're into this discussion, when I use SDL and the like, and I find creation functions that are paired with tidy-up functions that should be called at the end, I find it's an ideal time for some RAII and C++ style.
Create a new class, and in the constructor put the creation function(s) that have to be called. In the destructor, put the tidy-up function(s). Then, you can create an instance of your new class once at the start, and forget about it. When it falls out of scope, it will call all the tidy-up for you in its destructor.
Create a new class, and in the constructor put the creation function(s) that have to be called. In the destructor, put the tidy-up function(s). Then, you can create an instance of your new class once at the start, and forget about it. When it falls out of scope, it will call all the tidy-up for you in its destructor.
I've typically just been deleting things with the destructor rather than creating functions for it and putting them into the destructor. Keep in mind my projects are quite small for the moment and may not require an entire function to do clean up when I'm only tossing maybe 2 - 3 delete calls in there. I'll keep that in mind though.
My progress so far with SDL2 is basically creating a window, loading a sprite and moving him around. I've been beating myself up the past 6 hours trying to implement simplistic physics for things like gravity to get a "jump" function, heh. Ah well I'll figure it out sooner or later. To my surprise there are no tutorials on youtube covering it. Plenty of tutorials on how to create a window, load a sprite, animate it with a sprite sheet, but finding one for simplistic physics and a jumping function is hard to find!
I'm enjoying SDL quite a bit though none the less!
My progress so far with SDL2 is basically creating a window, loading a sprite and moving him around. I've been beating myself up the past 6 hours trying to implement simplistic physics for things like gravity to get a "jump" function, heh. Ah well I'll figure it out sooner or later. To my surprise there are no tutorials on youtube covering it. Plenty of tutorials on how to create a window, load a sprite, animate it with a sprite sheet, but finding one for simplistic physics and a jumping function is hard to find!
I'm enjoying SDL quite a bit though none the less!
Perhaps another way of looking at it is that today's complete program is tomorrow's small building block in a larger project. One of the aims ought to be to write reusable code, so that something which worked well as a stand-alone will be readily adapted to be re-used at a later date. In that context, the idea that things will be cleaned up by the OS in any case, might no longer be appropriate. Though here I'm talking in general and not about the specific case here.
| CGunn86 wrote: |
|---|
| I've been beating myself up the past 6 hours trying to implement simplistic physics for things like gravity to get a "jump" function, heh. Ah well I'll figure it out sooner or later. To my surprise there are no tutorials on youtube covering it. Plenty of tutorials on how to create a window, load a sprite, animate it with a sprite sheet, but finding one for simplistic physics and a jumping function is hard to find! |
I'm sure there are plenty of information about how to implement gravity and jumping in games out there. Note that these things doesn't have much to do with the language or library that you use, so the information you find will probably be more general so that it can be read by a bigger audience. If you limit yourself to articles about game physics with C++ and SDL2 you will have much harder time finding good (if any) information about it. I know this is not easy when you are new to programming, but eventually you should be able to read about something, understand it, and then implement it using whatever language/library you choose.
Simple jump function:
User indicates "jump".
Give object vertical speed of X.
Every subsequent time step:
Object is moved vertically an amount equal to object's current vertical speed
Object's vertical speed = current vertical speed - (gravity_value * duration_of_time_step)
If object is touching floor beneath, object's vertical speed = 0
User indicates "jump".
Give object vertical speed of X.
Every subsequent time step:
Object is moved vertically an amount equal to object's current vertical speed
Object's vertical speed = current vertical speed - (gravity_value * duration_of_time_step)
If object is touching floor beneath, object's vertical speed = 0
Last edited on
Topic archived. No new replies allowed.