C++ Heap ?

The difference is that if you create an array like array[400] then that array is something the compiler can account for itself, and the array ends up stored in the stack, which is part of the program's own memory. The obvious advantage to this is that the compiler will take care of the memory management for you. It will create the array when you need it, and deallocate it when it's out of scope. The problem is that the everything needs to be constant, or the compiler can't deal with it. You can't create an array of a variable size. That's when you use the heap, which is basically just a heap of memory outside of any applications that these programs can use as necessary. Using the new operator to dynamically allocate memory is basically a request by your program to get use of some extra memory outside of your program. The down side, of course, is that you are entirely responsible for keeping track of that memory. You have to be sure that you never lose track of any of your dynamically allocated memory, and that you delete all of it once you're done with it.

To expand on that, you only have 1Mb (usually) of stack space. And that 1Mb is used by all local variables and return addresses for function calls. If you run out of stack space, your program will crash.
If you use the heap, you're telling Windows (Well, the OS) that you want it to manage your memory for you. That allows you to allocate around 3Gb of data, if you consider virtual memory as well as physical RAM. The OS will take care of swapping data to and from disk for you if you run out of physical RAM.
The 3Gb limit is because if you have a 32-bit pointer, it can only address 4Gb of data. But the OS also has some reserved addresses that it can't use (such as the address of loaded DLLs, and NULL).

Quote:

That's when you use the heap, which is basically just a heap of memory outside of any applications that these programs can use as necessary.

"Outside of any applications" might be misleading. It implies that some application A can allocate memory from the heap (say at address 0x1000) and write to it, and application B could then read from 0x1000 and get the value that A wrote, which isn't the case unless you make some OS calls to allow that sort of thing, since each process gets it own (protected) memory space.

In addition to what Arek said, stack memory is limited. This means you will not be able to to do this:

// 64 MiB on 32 bit x86int bigArray[1024 * 1024 * 16];

(at least not without modifying the compiler's stack-size settings).

You also use dynamic allocation if you want to control the lifetime of your variable. The above array might only be needed for a specific function but would eat 64MiB of memory during the whole program runtime (provided it's declared on global scope or as static for some practical reason(s)).
If you use dynamic allocation, you are in control of the variable's lifetime and can create/delete it whenever needed.

HTH,
Pat.

Quote:

Original post by Evil Steve If you use the heap, you're telling Windows (Well, the OS) that you want it to manage your memory for you.

Steve, I know you probalby know this but this statement is missleading. YOu still manage the memory, as you have to allocate, use and delete it. Windows with plain C++ won't delete it for you.

Cheers
CHris

Quote:

Original post by chollida1 Quote: Original post by Evil Steve If you use the heap, you're telling Windows (Well, the OS) that you want it to manage your memory for you. Steve, I know you probalby know this but this statement is missleading. YOu still manage the memory, as you have to allocate, use and delete it. Windows with plain C++ won't delete it for you.

Sorry, you're right. I need more words [smile] By "manage", I mean it'll handle swapping to disk if needed.