0

In which all situations is it better to store data in the heap instead of the stack?

Till now, I haven't seen any situation in which the heap is absolutely necessary in languages like C; I haven't come across any code that takes a large amount of data, so large that it needs the heap too to hold the data. Apart from dynamic arrays, where else is it used? I usually make a large-sized array in the stack instead of making a dynamic one in the heap; my justification is that the heap is very slow as compared to the stack. Am I following the right practice? Thank you.

9th Aug 2021, 5:08 PM
Calvin Thomas
Calvin Thomas - avatar
11 Antworten
+ 2
The stack is where your code and data go in, whereas the heap is merely loose memory space used for dynamic allocation, as you mention. Typically small scale programs like you see in the examples on this site will almost never require dynamic allocation (C++ nearly eliminates the need for malloc and its analogs with new of course, but it's necessary for instantiating objects anyway). Some basic examples of requiring the heap is when you define a pointer, but don't assign it to a value immediately. For example: int* num; in this case, we have an int pointer, that doesn't point to anything yet. We can allocate a int to it with: num = malloc(sizeof(int)); The same goes for any other type, even on or within structs, for example if you define a simple struct as: struct SimpleStruct{ int* num; }; you'll have to use dynamic assignment to reserve space on the heap for the num, and if you wish to define a pointer to a SimpleStruct: struct SimpleStruct* struc = malloc(sizeof(SimpleStruct)); (*struc).num = malloc(sizeof(int)); you will have the same scenario. So yeah, you use the heap a lot with dynamically allocated arrays, but it's not limited to just that. After all, anything having to do with pointers WILL involve the heap in some way, even if the pointers defined reside on the stack. I think there are some exceptions to that, and that's when a variable defined on the stack is pointed to by a separate pointer: int num = 5; int* nump = & num; So it's basically pointing to a variable on the stack, rather than a location on the heap (correct me anyone, if I'm wrong on that).
9th Aug 2021, 5:53 PM
BootInk
BootInk - avatar
+ 2
You're right, of course, @Martin Taylor. Maybe I'm wrong, but I think there's generic use of the word "Stack" that I've heard before that refers to the entire process frame as a "stack", rather than the physical stack located in the program. Maybe that doesn't exist, and I'm just sounding stupid.
10th Aug 2021, 1:39 PM
BootInk
BootInk - avatar
+ 1
BootInk and Martin Taylor Thanks a lot for your replies.
10th Aug 2021, 2:33 AM
Calvin Thomas
Calvin Thomas - avatar
+ 1
Martin Taylor Why should the initialized and the un-initialized variables have a separate section for storage?
10th Aug 2021, 2:23 PM
Calvin Thomas
Calvin Thomas - avatar
+ 1
Martin Taylor I see, thank you very much.
11th Aug 2021, 3:26 AM
Calvin Thomas
Calvin Thomas - avatar
0
Martin Taylor Oh, I see. Now let's suppose this code: int main() { int a; a = 4; return 0; } Here, does the variable 'a' straight-away go to the bss section and later enter the data section when initialized with the value '4', or is the gcc compiler smart enough to just move the variable to the data section with the value '4'? Also, do variables occupy the same amount of memory in the data and the bss section? Thank you.
10th Aug 2021, 8:33 PM
Calvin Thomas
Calvin Thomas - avatar