Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Don't rewrite your old code

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Don't rewrite your old code
Neil Black
Member #7,867
October 2006
avatar

Oh yeah, I was decreasing the delay, which increased the speed... brain fart!

Trezker
Member #1,739
December 2001
avatar

Halflife sourcecode:
float m_frictionFraction; // Sorry, couldn't resist this name :)
dlls\triggers.cpp (line 56)

BAF
Member #2,981
December 2002
avatar

PossumDude - do you not know how to clean up after yourself? Your program seems to leak a nice chunk of memory, depending on the size of those bitmaps.

Neil Black
Member #7,867
October 2006
avatar

1) I don't really understand what leaking memory is, but I can tell it's important and I need to learn it, it's Google-time!

2) That program, as I have already stated, need rewriting. It is also unfinished, because they cut off my electricity when I had barely gotten things displaying properly. But I'm getting my electicity back on next week! I hope...

bamccaig
Member #7,536
July 2006
avatar

Memory leaks when memory is reserved by a program and never released back to the operating system. When the program closes the operating system doesn't know the memory is free so it will not give it to another program. That memory is essentially unusable until the computer restarts (or possible the operating system determines that it's not in use, but I don't think this happens).

**See following posts**

In other words, when you create a variable in your program, your program has to request memory from the operating system, which controls the entire computer. If it has the memory available it will probably grant it to you. If not, depending on the system, it will probably somehow message your program to indicate that there isn't enough memory. If your program doesn't handle this (probably an exception) your program will otherwise crash.

Once the operating system grants your program access to memory no other program should be allowed to use it (that is dependent on the operating system, but I assume XP or Vista do this; and I'm very certain that *nix systems do). That will ensure that another program doesn't overwrite a variable on you and mess up your program.

When your program is finished with memory, it should release it so the operating system can give it to some other program.

A simple example:

1class Object
2{
3private:
4 int mintX;
5 int mintY;
6public:
7 int X(void)
8 {
9 return mintX;
10 }
11 
12 void X(int intX)
13 {
14 mintX = intX;
15 }
16 
17 int Y(void)
18 {
19 return mintY;
20 }
21 
22 void Y(int intY)
23 {
24 mintY = intY;
25 }
26}
27 
28int main(void)
29{
30 int *intPointer = NULL; // Stores a memory address, not an int.
31 Object *objPointer = NULL; // Stores a memory address, not an Object.
32 
33 intPointer = new int[1]; // Create a new int and point to it with intPointer.
34 objPointer = new Object(); // Create a new Object and point to it with objPointer.
35 
36 /*
37 * What we have done is create two variables that store memory addresses. Then
38 * we instantiated an int and an Object and stored their memory addresses in
39 * intPointer and objPointer. If we refer to intPointer we are actually going
40 * to be getting a memory address, not the integer it points to. However, if
41 * we use the * operator with it, which translates to "the value pointed to
42 * by" we can access the actual integer. Therefore, *intPointer becomes "value
43 * pointed to by intPointer".
44 */
45 *intPointer = 5; // Store 5 in the memory space pointed to by intPointer.
46 
47 /*
48 * With objPointer we can reference it and it's properties the same way. For
49 * example, *objPointer.X() would return the value stored in mintX of
50 * our Object instance, which is pointed to by objPointer. We can also use the
51 * -> operator to get access to the members and methods of an object pointer,
52 * which will allow us to avoid using *. For example, objPointer->X() is the
53 * same as *objPointer.X().
54 */
55 
56 /*
57 * Set the mintX property of the Object instance pointed to by objPointer to
58 * 5. Set the mintY property of the Object instance pointed to by objPointer
59 * to 3.
60 */
61 *objPointer.X(5);
62 *objPointer.Y(3);
63 
64 /*
65 * Set the mintX property of the Object instance pointed to by objPointer to
66 * 6, this time using the -> operator instead of * and . operators. Set the
67 * mintY property of the Object instance pointed to by objPointer to 8, also
68 * using the -> operator instead of * and . operators.
69 */
70 objPointer->X(6);
71 objPointer->Y(8);
72 
73 /*
74 * Now lets illustrate the point to be made: MEMORY LEAKS. When a variable
75 * goes out of scope (such as the end of a function or the program) there are
76 * instructions to release the memory used by your program. I assume the
77 * compiler takes care of this, but I'm not completely sure. Anyway, that is
78 * when memory used by your variables are released to the operating system.
79 * However, when a pointer is released the memory being released is the memory
80 * that holds the memory address of the data, not the actual data. As a
81 * result, the actual memory used to store the data is orphaned. The reference
82 * is released (the pointer) and that memory is unusable until the program
83 * exits.
84
85 * Something to note is pointer scope: a pointer in a function will be
86 * released at the end of the function, which means you lose the address it
87 * points to and that memory is again "leaked". As a result, before your
88 * pointers go out of scope you should always release the data they point to,
89 * or pass the address somewhere else so you can continue to use it and
90 * release it later. Using malloc() to allocate your memory you should use
91 * free() to release it. Using the new operator to allocate your memory you
92 * should use the delete operator to release it.
93 */
94// delete intPointer; // Releases the memory pointed to by intPointer. I've
95 // commented it out to actually illustrate a memory leak.
96 intPointer = NULL; // We are overwriting the address with NULL (0 or \0) to
97 // illustrate that is no longer in use. Doing this before
98 // you release the data is bad because you're leaking that
99 // memory. Because we have no other reference/pointer to
100 // the instance and we never released it (because the
101 // delete statement is commented out) we are causing a
102 // memory leak.
103 
104 delete objPointer; // Releases the memory pointed to by objPointer.
105 objPointer = NULL; // We can no longer use the address that it points to
106 // because the operating system owns it again, so we set
107 // it to NULL (0 or \0) just to illustrate that.
108 
109 return 0;
110 
111 /* End of our program. Oooops! We leaked the integer instance. We actually
112 * leaked it when we set intPointer to NULL because we overwrote the address,
113 * making it impossible to release it because we don't know where it was.
114 * Apparently the operating system will free the resources when our program
115 * ends so it shouldn't be a problem in this program (apparently).
116 */
117}

Sorry if I went over too much, but I figured there's no point explaining just the new and delete stuff if you, or somebody else stumbling across this thread, doesn't understand a bit about pointers and memory addresses.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

That memory is essentially unusable until the computer restarts (or possible the operating system determines that it's not in use, but I don't think this happens).

Any decently modern operating system will free the memory once a program closes.

The main problem comes when your program runs for more than a few seconds, if you never free memory that you allocate, it'll keep building up and eventually run out of memory, cause the OS to start swaping stuff to disk, and then things get really slow.

If you new/malloc/create_bitmap/load_bitmap you must free the memory (delete/free/destroy_bitmap/destroy_bitmap) when you are done with it.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Thomas Fjellstrom said:

Any decently modern operating system will free the memory once a program closes.

Ah yes. So I guess when your program exits the operating system should be able to clean up any unreleased memory (makes logical sense). However, during the execution of your program you can hog a ton of memory that's not even in use anymore if you don't release it properly.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

However, during the execution of your program you can hog a ton of memory that's not even in use anymore if don't release it properly.

I think I just said that. Did you read the entire post?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Thomas Fjellstrom said:

I think I just said that. Did you read the entire post?

Shit no. Do you think I have time to read a fucking novel like that! Tone it down a bit.

Obviously, you're gonna freak out on that so allow me to apologize. That last post was really my "I'm embarassed as I should have known that and yes, I think he's right" post.

Thomas Fjellstrom said:

The main problem comes when your program runs for more than a few seconds, if you never free memory that you allocate, it'll keep building up and eventually run out of memory, cause the OS to start swaping stuff to disk, and then things get really slow.

I thought that the operating system usually throws large idle programs out to swap in an attempt to free memory ahead of time and also so it can load things into memory that it predicts will be needed soon. I'm not really an expert on operating systems though. Anybody know of a good OS writing tutorial? {smiley}

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Shit no. Do you think I have time to read a fucking novel like that! Tone it down a bit.

Uh, You seem to be upset :o

Quote:

Obviously, you're gonna freak out on that so allow me to apologize.

I freaked out? It was a simple question.

Quote:

I thought that the operating system usually throws large idle programs out to swap in an attempt to free memory ahead of time and also so it can load things into memory that it predicts will be needed soon.

Sorta. It mainly swaps when asked. I something needs ram, and theres no physical ram left, the OS will swap some pages to free enough (and maybe more) for the request.

Linux will end up swaping some way underused programs if they almost are never used, and the file/disk cache is well used. (it'll swap stuff to make room for disk cache)

edit: Also, Vista has added proper file/disk caching as well, so I'll bet it will do the same. Of course it also added extra app caching features with flash drives and whatnot.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Thomas Fjellstrom said:

Uh, You seem to be upset

No, that was said sarcastically. I would have made it more obvious, but I assume it's still EFW. When does that end exactly?

Thomas Fjellstrom said:

I freaked out? It was a simple question.

I didn't want you to freak out because I referred to your post as a novel. I'm sure regular users have realized by now that I often have long replies.

And it sounded like you thought I was trying to take credit for your answer. I just wanted to clear it up... I can see now that it's gonna take a while.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

I can see now that it's gonna take a while.

Not at all. I just have a small beef with people not reading posts. :)

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Joel Pettersson
Member #4,187
January 2004

Quote:

Any decently modern operating system will free the memory once a program closes.

Indeed; hence, (warning; evil suggestion) you can often greatly optimize shut-down times of programs using a lot of dynamically allocated memory - especially ones with a ton of destructors or other cleanup functions to be called - by simply doing a quick-and-dirty exit, focusing proper memory management on the parts of the program active during its lifetime.

bamccaig
Member #7,536
July 2006
avatar

Joel Pattersson said:

...by simply doing a quick-and-dirty exit,...

My concern is which is faster and more reliable: explicitly cleaning things up or the operating system cleaning up the mess you leave behind?

Thomas Fjellstrom
Member #476
June 2000
avatar

The os can probably just defer the freeing of stuff. If the program isn't meant to do anything fancy, and doesn't run long, you don't NEED to free any of the mem yourself.

Unfortunately not all resources are memory, theres also threads, Window Handles, GDI resources, X11 Resources, and occasionally, if you don't free those sorts of things, they may not be freed correctly. Win 9x has always had a NASTY problem with not freeing ANY GDI, KERNEL32, or USER32 handles by itself when an app crashes or even just forgets to free stuff. I've you've ever seen the GUI turn into a copy of Win3.1, you just ran out of GDI handles.

Its a lot harder to do the same in 2k and XP though, since its based on a much better kernel.

Personally, not freeing stuff feels dirty, and wrong. I prefer to do things the right way when I can.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Thomas Fjellstrom said:

Personally, not freeing stuff feels dirty, and wrong. I prefer to do things the right way when I can.

I'm the same way. For me it's a compulsion. That's also why I edit forum posts so often. If I don't do things "perfectly" I'm compelled to fix them.

(I've been drinking Canadian beer... I don't know if I'm making spelling/grammar errors right now... :'()

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

If I don't do things "perfectly" I'm compelled to fix them.

Yeah, I usually try, but some of the time I don't even notice the errors, and anal people like to throw witty remarks around about my errors (so sue me if I have a mild case of dyslexia and really bad recall).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

BAF
Member #2,981
December 2002
avatar

Quote:

Its a lot harder to do the same in 2k and XP though, since its based on a much better kernel.

I actually have hit that before (tons of leaked GDI handles in XP). XP tops out around 32,000 handles, and when they get leaked by various crappy programs over the course of 8-10 weeks (my average reboot cycle), you can end up having those issues. However, it's normally programs that stay running. Also, if you log out/back on on XP, it seems to clean out a bunch of those leaked GDI handles.

[edit]
X-Chat falls under the crappy programs category. It only has 129 GDI handles, however, somehow it has managed ot eat up 5,017 handles and 1,152 threads.

Joel Pettersson
Member #4,187
January 2004

Quote:

My concern is which is faster and more reliable: explicitly cleaning things up or the operating system cleaning up the mess you leave behind?

The OS will catch it all, so the reliability is not affected when you perform a given part of the memory freeing manually. And doing it manually often requires many relatively costly freeing calls - and often executing much other code, particularly in heavily OO-structured programs where multiple destructurs may be called for each of many objects. Slightly slower at best, much slower at worst.

Quote:

Unfortunately not all resources are memory, ...

And there you can have reason to do things "properly". When it is guaranteed that avoiding running code won't do any harm, though, it makes no more sense to put it in than adding a sleep call.

Quote:

If I don't do things "perfectly" I'm compelled to fix them.

That goes for me as well, only what I see as being "perfect" is different; I go to great (sometimes semi-obsessive) lengths to avoid redundancy and overhead.

bamccaig
Member #7,536
July 2006
avatar

Joel Pettersson said:

That goes for me as well, only what I see as being "perfect" is different; I go to great (sometimes semi-obsessive) lengths to avoid redundancy and overhead.

Yeah, I would say it is semi-obsessive of me as well. Refer to the Off-Topic thread started a few weeks ago titled Post a weird fact about you...........

Or for a direct link to those relevant posts:

What I see as being perfect is probably relative to the situation.

BAF
Member #2,981
December 2002
avatar

You are OCD, yet you still write unclean PHP code? That doesn't sound right to me.

bamccaig
Member #7,536
July 2006
avatar

BAF said:

You are OCD, yet you still write unclean PHP code? That doesn't sound right to me.

I've never been diagnosed. As far as unclean PHP code, that depends on your definition of unclean. To me it was cleaner. Dynamically-typed langauges are considered unclean to me, so I only use them when I have to.

 1   2   3 


Go to: