Stack Vs Heap?

slap

Hi,

N00b question. Just a bit confused.
All help appreciated.

Value types (int etc.) are stored on the stack. Objects (new Class()) are stored on the heap. Correct so far?

References to objects (Class myClass = new Class(), => myClass) are stored on the stack. Correct?

But most objects contain value types (ints, strings). So where are these being stored? Back on the stack? If so, what is being stored on the heap?

Thanks,
Slap

Sparks

Stack-v-heap decisions vary with both language and compiler/platform. But assuming you're talking about C/C++ on a normal PC, whether something is stored on the stack or the heap tends to depend on how it's declared rather than what it is. Declaring it using new() or malloc() should normally store it on the heap; declaring it (edit: okay, defining it) directly (like int a=0;) should store it on the stack. You run into exceptions in more esoteric cases, but if you're just starting off, that's a reasonable rule of thumb for those languages.

fasty

What language?

In C and C++ is you allocate memory on the heap for a structure or class, then the contents of that data type are put in that memory be they ints, strings, whatever.

Since you specifically refer to value types, I'm guessing you're talking about C# where the term has meaning. Value types in an object on the managed heap are also on the managed heap as far as I know.

Tobias Greeshman

slap wrote: »

References to objects (Class myClass = new Class(), => myClass) are stored on the stack. Correct?

I assume this is java or some variation language like C# you're talking about.

AFAIK references are just normal variables/aka pointers and would be just local variables and stored on the stack, while what they point to or reference would be created elsewhere, probably the heap. If you think about java reference variables like this then you won't go far wrong.

slap

Thanks for the replies.

Well spotted, I am talking about C#. Apologies for not mentioning that, but I didn't know there would be differences between languages .

Still a bit confused though.
If you "allocate memory on the heap for a structure or class, then the contents of that data type are put in that memory be they ints, strings, whatever", that makes sense.
But what kind of value types are put on the stack then? Aren't they all contained within some object and thus stored on the heap, as per above?

NeverSayDie

This series of articles appears to explain the process in some detail OP, should help;
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx

OwenM

If your using C# or Java why does it matter?

Sparks

OwenM wrote: »

If your using C# or Java why does it matter?

Because a programmer who doesn't know what his or her language does down on the silicon doesn't really know how to program.

NeverSayDie

Sparks wrote: »

Because a programmer who doesn't know what his or her language does down on the silicon doesn't really know how to program.

What he said. Plus the garbage collectors in the Framework and the Java runtime aren't omnipotent - there are assorted gotchas, performance issues, quirks and other things to be aware of, some of them relating to stack and heap behaviour.

One of the great things about tech like Java and .NET is that they shield you from having to worry about that sort of thing for most circumstances, which saves considerable time, hassle and risk, but knowing your tools and your platform still matters if you want to be good at your trade.

Naikon

I would be a tad worried if someone claimed to be a professional programmer, but didn't grasp the concept of a memory address ala C, or the difference between static and dynamic memory allocation. Stack space does not have the same degree of granular control in comparison to memory taken from the heap. Having to manage your own memory tends to be the compromise though. If your actual algorithms implement very dynamic structures in the code, you better manage the resources you have as best you can. Managed enviroments like C# and Java are all well and good, but you can't trust a garbage collector as gospel. Yes, memory leaks are still possible with garbage collectors. Your brain and memory analysis tools like Valgrind are your best friend. Never trust the runtime enviroment to do all the work.

slap

Thanks everyone for all your help and advice.
Well appreciated.
Slap