Don't rewrite your old code

Don't rewrite your old code

Neil Black

Member #7,867

October 2006

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

Trezker

Member #1,739

December 2001

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

[My github]

BAF

Member #2,981

December 2002

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.

BAF.zone | SantaHack!

Neil Black

Member #7,867

October 2006

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

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:
  int mintX;
  int mintY;
6public:
  int X(void)
  {
      return mintX;
  }
11 
  void X(int intX)
  {
      mintX = intX;
  }
16 
  int Y(void)
  {
      return mintY;
  }
21 
  void Y(int intY)
  {
      mintY = intY;
  }
26}
27 
28int main(void)
29{
  int *intPointer = NULL;     // Stores a memory address, not an int.
  Object *objPointer = NULL;  // Stores a memory address, not an Object.
32 
  intPointer = new int[1];    // Create a new int and point to it with intPointer.
  objPointer = new Object();  // Create a new Object and point to it with objPointer.
35 
  /*
   *  What we have done is create two variables that store memory addresses. Then
   *  we instantiated an int and an Object and stored their memory addresses in
   *  intPointer and objPointer. If we refer to intPointer we are actually going
   *  to be getting a memory address, not the integer it points to. However, if
   *  we use the * operator with it, which translates to "the value pointed to
   *  by" we can access the actual integer. Therefore, *intPointer becomes "value 
   *  pointed to by intPointer".
   */
  *intPointer = 5;  // Store 5 in the memory space pointed to by intPointer.
46 
  /*
   *  With objPointer we can reference it and it's properties the same way. For
   *  example, *objPointer.X() would return the value stored in mintX of
   *  our Object instance, which is pointed to by objPointer. We can also use the 
   *  -> operator to get access to the members and methods of an object pointer,
   *  which will allow us to avoid using *. For example, objPointer->X() is the
   *  same as *objPointer.X().
   */
55 
  /*
   *  Set the mintX property of the Object instance pointed to by objPointer to
   *  5. Set the mintY property of the Object instance pointed to by objPointer
   *  to 3.
   */
  *objPointer.X(5);
  *objPointer.Y(3);
63 
  /*
   *  Set the mintX property of the Object instance pointed to by objPointer to
   *  6, this time using the -> operator instead of * and . operators. Set the
   *  mintY property of the Object instance pointed to by objPointer to 8, also
   *  using the -> operator instead of * and . operators.
   */
  objPointer->X(6);
  objPointer->Y(8);
72 
  /*
   *  Now lets illustrate the point to be made: MEMORY LEAKS. When a variable
   *  goes out of scope (such as the end of a function or the program) there are
   *  instructions to release the memory used by your program. I assume the
   *  compiler takes care of this, but I'm not completely sure. Anyway, that is
   *  when memory used by your variables are released to the operating system.
   *  However, when a pointer is released the memory being released is the memory
   *  that holds the memory address of the data, not the actual data. As a
   *  result, the actual memory used to store the data is orphaned. The reference
   *  is released (the pointer) and that memory is unusable until the program
   *  exits.
84
   *  Something to note is pointer scope: a pointer in a function will be
   *  released at the end of the function, which means you lose the address it
   *  points to and that memory is again "leaked". As a result, before your
   *  pointers go out of scope you should always release the data they point to,
   *  or pass the address somewhere else so you can continue to use it and
   *  release it later. Using malloc() to allocate your memory you should use
   *  free() to release it. Using the new operator to allocate your memory you
   *  should use the delete operator to release it.
   */
94//  delete intPointer;   // Releases the memory pointed to by intPointer. I've
                       // commented it out to actually illustrate a memory leak.
  intPointer = NULL;   // We are overwriting the address with NULL (0 or \0) to
                       // illustrate that is no longer in use. Doing this before
                       // you release the data is bad because you're leaking that 
                       // memory. Because we have no other reference/pointer to
                       // the instance and we never released it (because the
                       // delete statement is commented out) we are causing a
                       // memory leak.
103 
  delete objPointer;   // Releases the memory pointed to by objPointer.
  objPointer = NULL;   // We can no longer use the address that it points to
                       // because the operating system owns it again, so we set
                       // it to NULL (0 or \0) just to illustrate that.
108 
  return 0;
110 
  /*  End of our program. Oooops! We leaked the integer instance. We actually
   *  leaked it when we set intPointer to NULL because we overwrote the address,
   *  making it impossible to release it because we don't know where it was.
   *  Apparently the operating system will free the resources when our program
   *  ends so it shouldn't be a problem in this program (apparently).
   */
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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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?

bamccaig

Member #7,536

July 2006

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:

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}

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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

Quote:

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

I freaked out? It was a simple question.

Quote:

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.

bamccaig

Member #7,536

July 2006

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.

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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.

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

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?

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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.

bamccaig

Member #7,536

July 2006

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... :'()

--
I mean the best with what I say. It doesn't always sound that way.

Thomas Fjellstrom

Member #476

June 2000

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).

BAF

Member #2,981

December 2002

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.

BAF.zone | SantaHack!

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

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.

--
I mean the best with what I say. It doesn't always sound that way.

BAF

Member #2,981

December 2002

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

BAF.zone | SantaHack!

bamccaig

Member #7,536

July 2006

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.

--
I mean the best with what I say. It doesn't always sound that way.