Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Sieggy

windows stack and heap storage thoughts

This topic is 6926 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got a question here and please forgive me if it draws out a bit. Also please feel free to share your thoughts on this subject; I'm curious to hear what others have to say: I've avoided heap storage where possible for the obvious performance reasons and also memory leaks. I'm a UNIX developer by day and my app needs to stay up weeks at a time so memory leaks are a pain (the other reason). Consequently, I frown on excessive use of dynamic allocation and personally I only use it unless it fits the problem at hand. However I've found plenty of people who just use new and delete tons, even for single instance objects that live only in a single function. For instance: void myfunct (void) { CMyClass* a = new CMyClass(); //do whatever delete a; } Why bother with new and delete in the above case at all? It seems to be a waste of performance and also leaves you open to leaks. Anyhow, the question. I was sharing my thoughts on the subject with a new team member, a C++ newbie. He took my thoughts to his mentor who countered me saying that he prefers heap in windows because windows has a set limit on available stack and heap is a lot larger. I researched and read information that is contradictory to that. So: -So does Windows enforced a set stack size? -If so how is it defined? -How can it be enlarged? I'm curious to hear what others say. So please share you thoughts and wisdom! Thanks as always, Sieggy Edited by - Sieggy on 5/4/00 8:03:06 AM

Share this post


Link to post
Share on other sites
Advertisement
According to my favorite book (Teach yourself C++ in 24 Hours by Jesse Liberty), the stack is a lot smaller than the heap. It doesn''t mention anything about stack size changing, but I think I saw a post about someone playing with their stack size here on gamedev. Also, don''t memory leaks go away when the program closes? (I know this wouldn''t help you if you need it to run 24/7 ) At the very least, they go away when you restart (btw, I am talking about the leaked memory, not the leak itself), right? A very good friend of mine insists that once memory has been leaked, it is gone forever, and you need to buy new RAM. Luckily for him, he has a huge supply on hand...

--------------------


You are not a real programmer until you end all your sentences with semicolons;

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

Share this post


Link to post
Share on other sites
That''s pretty humorous! I guess that''s why I have so little memory left: I played too much of Ultima IX!

Right, though, the leaks should be gone on app exit and I do tend to be a little biased since my day job depends on me writing code the exits as little as possible and leaks can be killer on long term apps.

Share this post


Link to post
Share on other sites
Using the MS linker, there are 2 ways of setting you stack size. The first is using the /STACK command line parameter and the second is using the STACKSIZE keyword in your .DEF file. (You can also change a stack setting using the EXEBIN utility)

The default stack size is 1MB, however, when you program runs, only a small percentage of the stack is actually realized. It will grow when the stack generates an access violation. But, to the best of my understanding, it will not grow past the size of the stack setting in the executable.

Now, IMHO, I agree Sieggy. There is little point to allocating temporary objects from the heap AS LONG AS you are aware of how these temporary will stress your stack. I work in the industrial automation industry where the software has to run for months on end. I am sometimes shocked at how many programers just let memory leak all over the place.

Tim

Share this post


Link to post
Share on other sites
Hi guys,

I was just wondering if you can explain memory leaks to me. Is that when you have created an object, and forget to delete it?

Thanks,

Nick

Share this post


Link to post
Share on other sites
Basically yes,

Consider this code:

void myfunc (void)
{
int* a = new int;

//do stuff
}

In the above you've allocated an int off of the heap. The operating system returned to you the block of memory (if it was available) and assigned the starting address to your pointer. As you can see the pointer goes out of scope with the end of the function however that block of memory is still there and will be until it is released (with delete or free if you are using malloc). Since we no longer have a pointer to that address we can't delete but the memory is still there, hence it's a leak. They're other variations of course but essentially its just memory you ask for but you never give back. If it's a method you call often, what might be considered trivial in this case (2 bytes lost for this int) can quickly add up as well as degrade the performance of future calls to new/malloc while your app is running. Eventually if the leak(s) are bad enough your app will slow down, possibly exhaust its heap, and depending on your platform crash.

Sieggy

Edited by - Sieggy on 5/4/00 9:01:34 AM

Share this post


Link to post
Share on other sites
That post reminded me of a related question I have...

If I write a function like so:

char *ReadFile(FILE *theFile)
{
char *StringFromFile = new char[80];
fgets(StringFromFile, 79, theFile);
return StringFromFile;
}

And then use it like this:

if (strcmp("Hello", ReadFile(MyFile)) == 0)
// do something

Is there any way to get that memory allocated in the ReadFile function back? I would really like to be able to do this in my functions, but I never have because every call allocates 80 bytes that I can''t seem to get back. This method is a lot better than passing a char * to the function to fill, assuming that you can free the memory when you are done.

--------------------


You are not a real programmer until you end all your sentences with semicolons;

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

Share this post


Link to post
Share on other sites
If you don''t keep the address of the allocated memory in some variable, you can''t reclaim it...

So it''s pretty important to keep track of the address of memory that has been allocated.

Erik

Share this post


Link to post
Share on other sites
Erik is right.

If you get longer with C++, there''s something call auto_ptr that wrap around your naked pointer... Pointers are ugly when they are naked. Now let''s see auto_ptr in action:


void myfunc (void)
{
std::auto_ptr a(new int);
// do stuff...
}


When this function exits, a is automatically deleted. That''s what most people call Resource Management. (is it?)

See here: Strong pointer and Resource Management in C++

Share this post


Link to post
Share on other sites
Thanks Sieggy for you informative message! I got it!

"If you build it, it will crash."

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!