I understand that the stack is temporary, while it is stored in the {} scope, meaningful types are stored on the stack, and the variable contains its address on the stack, the reference types store a link to the heap in which the object is stored on the stack.
But why not leave something alone? Yes, a stack with a volume of only 1mb, but why it could not be expanded?
What are the advantages of this approach and why was it worth creating such a division?
Naturally, I was searching, but little by little.

  • but why it could not be expanded - at the expense of what for example? - Grundy
  • one
    @kovadim, but why? - Ep1demic
  • one
    Before that, someone said that it was easier to get rid of the heap, but Richter wrote the opposite, that with each allocation of memory, they say that it’s time and costly, but I wanted to go to the stack - say, to a friend, hold it without problems. And operating large objects on the heap is easier than on the stack. Because of which? Is it easier to get a pointer or what? From my considerations, the stack is strictly a consistent magnitude and dragging constantly objects, and if also heavy - long and low producer but not knowing how to prove it, is there anyone who can? Thank you all for such a violent reaction, honestly, I did not expect - recovery
  • 2
    Allocating memory in the stack is just to change one register (in Sharp, there may be a little bit of overlays, for this is a controlled language). Heap allocation is, at best, a search in a pre-allocated memory for a suitable piece of memory. In the worst case, this is an appeal to the operating system. And this is context switching, swapping and a lot of things (depending on appetites). - KoVadim
  • one
    @KoVadim, to a heap in a sharpe - in most cases, too, just move the pointer. If garbage collection does not start. - Qwertiy ♦

1 answer 1

For a start, a bunch, like a stack, is an implementation detail. The language standard does not prescribe the use of heaps to store objects.

In the Microsoft implementation of C #, the heap is used because it is convenient to place long-lived objects in it.

No matter how large the stack would be, it works in such a way that at the end of the function the objects allocated on the stack die. Therefore, if the lifetime of the object exceeds (or potentially exceeds) the execution time of the function that created it, the stack for such an object is not suitable.

Worse, an object can only be released from the stack after all previous objects have been released. This means that in the code

string f() { StringBuilder sb = new StringBuilder(); // цикл заполнения string s = sb.ToString(); return s; }

The sb object that is created before the string object will be on the stack and cannot be released until the calling function needs the s object!

Of the two entities — heaps and stacks — it is easier to get rid of the stack , and select all the objects in the heap. The language standard does not prescribe that stack objects must die with the stack frame (the language standard does not mention the stack at all), so if such objects are eaten sometime later by the garbage collector, nothing terrible will happen. But this is less effective than placing variables on the stack, because it increases the load on the garbage collector.

  • 3
    Comments are not intended for extended discussion; conversation moved to chat . - Nofate ♦