Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Clean Up  (Read 4737 times)

0 Members and 1 Guest are viewing this topic.

kidchameleon

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Clean Up
« on: January 25, 2011, 01:11:35 am »
Hi All,

Apologies if this is a very noob question. I'm looking for information on what to do when my game closes. I understand that I need to  free up memory that is being used my my game ie. memory for images, sounds etc... How would I go about this? I've searched documentation looking for keywords needed but am not having much success. Should I free memory held by arrays, floats integers etc or just memory used by resources? Do you guys know of any good tutorials/articles that would teach me about memory management in C++? I'm just so used to C# and Java taking care of this for me, this sort of thing is kind of new to me. Any help would be appreciated.

Cheers.

Kid.

darekg11

  • Full Member
  • ***
  • Posts: 127
    • View Profile
Clean Up
« Reply #1 on: January 25, 2011, 08:55:52 am »
Yes, You have to free all allocated memeory, for exmaple to delete imgae in C binding of SFML You have:
sfImage_Destroy;

Also if You allocated some memory dynamically You need to free it also.

Google information about new and delete operators.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Clean Up
« Reply #2 on: January 25, 2011, 09:14:59 am »
The problem is that in C++ you differentiate between two types of memory. Stack memory and Heap memory.

The stack memory is any variable which you create normally. Example:
Code: [Select]

void otherFunc()
{
        // Lets say that SomeStruct contains 4 ints which makes it 4*4 bytes big.
        SomeStruct aStruct;
}

int main()
{
        // Float if I remember correctly is 4 bytes big.
        float someFloat;
        otherFunc();
        return 0;
}


Here we create first a float which takes 4 bytes in memory. Push the stack into a new function called otherFunc and here we create aStruct of type SomeStruct. This takes 16 bytes. So at this point we are using 20 bytes of memory. Then when we exit the otherFunc function we pop the stack and any memory allocated "on-the-stack" here is de-allocated. So when we reach main() again we are only using 4 bytes.

So stack-allocated memory don't need us to manage it for them. This is them memory we mostly want to work with as it results in less errors and bugs. The problem is to make it consistent. As we progress trough the application we will enter and exit a lot of functions and methods making it quite hard in a real application to always keep the desired variables in memory.

This is what we have Heap memory for. To allocate on the heap you use the new and new[] keywords. The main difference between heap and stack memory is who manages it. Stack memory can be said to be managed at compile time, the compiler is able to see when and where to create and destroy the specific memory. Heap memory on the other hand is managed by you, the programmer. Also it forces us to work with pointers which is we want to avoid. So by using heap memory we get two more error-prune areas. Why we have Heap memory is because sometimes, that's the only way to be able to do something. Like growing arrays.

And to cleanup the code you use the delete and delete[] keywords. Though depending on the application you might or might not need them. Though it's good praxis to always clean up your code. Here's an example:
Code: [Select]

SomeStruct *AllocateData()
{
        return new SomeStruct();
}

int main()
{
        SomeStruct *theData = AllocateData();
        delete theData;
        return 0;
}


Here you can see that the memory persists even though we exit a function.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Clean Up
« Reply #3 on: January 25, 2011, 10:17:12 am »
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

kidchameleon

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Clean Up
« Reply #4 on: January 25, 2011, 11:00:47 pm »
Groogy, darekg11,

Thanks for taking the time to reply, it has been very helpful. I'm getting a better understanding of all this now.

Cheers,

Kid.

JAssange

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Clean Up
« Reply #5 on: January 26, 2011, 01:31:43 am »
Also just so you're aware, if you fail to free memory before closing the OS will free it for you on Windows, Mac or Linux. Some of the more esoteric operating systems won't.

Silvah

  • Guest
Clean Up
« Reply #6 on: January 26, 2011, 12:19:31 pm »
Quote from: "JAssange"
Also just so you're aware, if you fail to free memory before closing the OS will free it for you on Windows, Mac or Linux. Some of the more esoteric operating systems won't.
Partially untrue, Windowses 9x don't always free memory at exit (I wonder whether anyone still cares about these systems, though).

JAssange

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Clean Up
« Reply #7 on: January 26, 2011, 12:28:55 pm »
Quote from: "Silvah"
Quote from: "JAssange"
Also just so you're aware, if you fail to free memory before closing the OS will free it for you on Windows, Mac or Linux. Some of the more esoteric operating systems won't.
Partially untrue, Windowses 9x don't always free memory at exit (I wonder whether anyone still cares about these systems, though).

I was under the impression that that only applied to GDI handles and the like, I can't imagine the system managing to stay up as long as it does (albeit not very long) if you were 'losing' ram when apps didn't free it.

 

anything