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

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.

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.

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

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

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

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.

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

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++

Thanks Sieggy for you informative message! I got it!

"If you build it, it will crash."