I understand how to create a `struct` on the heap using `malloc`. Was looking for some documentation regarding creating a `struct` in C on the stack but all docs. seem to talk about struct creation on heap only. 

How to create a struct on the stack in C?

I&#39;m currently working on a very performance critical program and one path I decided to explore that may help reduce resource consumption was increasing my worker threads&#39; stack size so I can move most of the data (`float[]`s)  that I&#39;ll be accesing onto the stack (using [`stackalloc`](http://msdn.microsoft.com/en-us/library/cx9s2sy4(v=vs.80).aspx)).

I&#39;ve [read](https://stackoverflow.com/a/823729/2246344) that the default stack size for a thread is 1 MB, so in order to move all my `float[]`s I would have to expand the stack by approximately 50 times (to 50 MB~).

I understand this is generally considered &quot;unsafe&quot; and isn&#39;t recommended, but after benchmarking my current code against this method, I&#39;ve discovered a *530%* increase in processing speed! So I can not simply pass by this option without further investigation, which leads me to my question; what are the dangers associated with increasing the stack to such a large size (what could go wrong), and what precautions should I take to minimise such dangers?

My test code,

    public static unsafe void TestMethod1()
    {
        float* samples = stackalloc float[12500000];

        for (var ii = 0; ii &lt; 12500000; ii++)
        {
            samples[ii] = 32768;
        }
    }

    public static void TestMethod2()
    {
        var samples = new float[12500000];

        for (var i = 0; i &lt; 12500000; i++)
        {
            samples[i] = 32768;
        }
    }

What are the dangers when creating a thread with a stack size of 50x the default?

I&#39;m new to Go and I&#39;m experiencing a bit of cognitive dissonance between C-style stack-based programming where automatic variables live on the stack and allocated memory lives on the heap and Python-style stack-based-programming where the only thing that lives on the stack are references/pointers to objects on the heap.

As far as I can tell, the two following functions give the same output:

	func myFunction() (*MyStructType, error) {
		var chunk *MyStructType = new(HeaderChunk)

		...

		return chunk, nil
	}


	func myFunction() (*MyStructType, error) {
		var chunk MyStructType

		...

		return &amp;chunk, nil
	}

i.e., allocate a new struct and return it.

If I&#39;d written that in C, the first one would have put an object on the heap and the second would have put it on the stack. The first would return a pointer to the heap, the second would return a pointer to the stack, which would have evaporated by the time the function had returned, which would be a Bad Thing.

If I&#39;d written it in Python (or many other modern languages except C#) example 2 would not have been possible.

I get that Go garbage collects both values, so both of the above forms are fine. 

To quote:

&gt; Note that, unlike in C, it&#39;s perfectly OK to return the address of a
&gt; local variable; the storage associated with the variable survives
&gt; after the function returns. In fact, taking the address of a composite
&gt; literal allocates a fresh instance each time it is evaluated, so we
&gt; can combine these last two lines.
&gt;
&gt; http://golang.org/doc/effective_go.html#functions

But it raises a couple of questions.

1. In example 1, the struct is declared on the heap. What about example 2? Is that declared on the stack in the same way it would be in C or does it go on the heap too?

2. If example 2 is declared on the stack, how does it stay available after the function returns?

3. If example 2 is actually declared on the heap, how is it that structs are passed by value rather than by reference? What&#39;s the point of pointers in this case?

Stack vs heap allocation of structs in Go, and how they relate to garbage collection

In C, I know I can dynamically allocate a two-dimensional array on the heap using the following code:

    int** someNumbers = malloc(arrayRows*sizeof(int*));

    for (i = 0; i &lt; arrayRows; i++) {
        someNumbers[i] = malloc(arrayColumns*sizeof(int));
    }

Clearly, this actually creates a one-dimensional array of pointers to a bunch of separate one-dimensional arrays of integers, and &quot;The System&quot; can figure out what I mean when I ask for:

    someNumbers[4][2];

But when I statically declare a 2D array, as in the following line...:

    int someNumbers[ARRAY_ROWS][ARRAY_COLUMNS];

...does a similar structure get created on the stack, or is it of another form completely? (i.e. is it a 1D array of pointers? If not, what is it, and how do references to it get figured out?)

Also, when I said, &quot;The System,&quot; what is actually responsible for figuring that out? The kernel? Or does the C compiler sort it out while compiling?

How are multi-dimensional arrays formatted in memory?

Are all of the following statements true?

    vector&lt;Type&gt; vect; //allocates vect on stack and each of the Type (using std::allocator) also will be on the stack
    
    vector&lt;Type&gt; *vect = new vector&lt;Type&gt;; //allocates vect on heap and each of the Type will be allocated on stack
    
    vector&lt;Type*&gt; vect; //vect will be on stack and Type* will be on heap. 

How is the memory allocated internally for `Type` in a `vector` or any other STL container?


When vectors are allocated, do they use memory on the heap or the stack?

    int[] myIntegers;
    myIntegers = new int[100];

In the above code, is new int[100] generating the array on the heap? From what I&#39;ve read on CLR via c#, the answer is yes. But what I can&#39;t understand, is what happens to the actual int&#39;s inside the array. As they are value types, I&#39;d guess they&#39;d have to be boxed, as I can, for example, pass myIntegers to other parts of the program and it&#39;d clutter up the stack if they were left on it all the time. Or am I wrong? I&#39;d guess they&#39;d just be boxed and would live on the heap for as long the array existed.

Arrays, heap and stack and value types

I want to do DFS on a 100 X 100 array. (Say elements of array represents graph nodes) So assuming worst case, depth of recursive function calls can go upto 10000 with each call taking upto say 20 bytes. So is it feasible means is there a possibility of stackoverflow? 

What is the maximum size of stack in C/C++?

&gt; Please specify for gcc for both  
&gt; 1) cygwin on Windows  
&gt; 2) Unix  

What are the general limits?

C/C++ maximum stack size of program on mainstream OSes

When reading about assembler I often come across people writing that they *push* a certain register of the processor and *pop* it again later to restore it&#39;s previous state.

- How can you push a register? Where is it pushed on? Why is this needed?
- Does this boil down to a single processor instruction or is it more complex? 

What is the function of the push / pop instructions used on registers in x86 assembly?

I&#39;m currently trying to understand how the stack works, so I&#39;ve decided teach myself some [assembly language][1], I&#39;m using this book:

http://savannah.nongnu.org/projects/pgubook/ 

I&#39;m using [Gas][2] and doing my development on [Linux Mint][3].

I&#39;m a bit confused by something:

As far as I was aware a stack is simply a data structure. So I assumed if I was coding in assembly I&#39;d have to implement the stack myself. However this doesn&#39;t seem to be the case as there are commands like

    pushl
    popl

So when coding in assembly for the [x86][4] architecture and using the Gas syntax: is the stack just a data structure that&#39;s already implemented? Or is it actually implemented at the hardware level? Or is it something else? Also would most assembly languages for other chip sets have the stack already implemented?

I know this is a bit of a foolish question but I&#39;m actually quite confused by this.

  [1]: http://en.wikipedia.org/wiki/Assembly_language
  [2]: http://en.wikipedia.org/wiki/GNU_Assembler
  [3]: http://en.wikipedia.org/wiki/Linux_Mint
  [4]: http://en.wikipedia.org/wiki/X86


How does the stack work in assembly language?

I have an array declaration like this:

    int a[];

Here `a` is an array of primitive `int` type. Where is this array stored? Is it stored on heap or stack? This is a primitve type `int`, all primitive types are not stored on heap.

Is a Java array of primitives stored in stack or heap?

I am getting confused with memory allocation basics between **Stack vs Heap**. As per the standard definition (things which everybody says), all **Value Types** will get allocated onto a **Stack** and **Reference** Types will go into the **Heap**.  

Now consider the following example:

    class MyClass
    {
        int myInt = 0;    
        string myString = &quot;Something&quot;;
    }
    
    class Program
    {
        static void Main(string[] args)
        {
           MyClass m = new MyClass();
        }
    }

Now, how does the memory allocation will happen in c#? Will the object of `MyClass` (that is, `m`) will be completely allocated to the Heap? That is, `int myInt` and `string myString` both will go to heap?  

Or, the object will be divided into two parts and will be allocated to both of the memory locations that is, Stack and Heap?


Memory allocation: Stack vs Heap?

I know this sounds like a general question and I&#39;ve seen many similar questions (both here and on the web) but none of them are really like my dilemma.

Say I have this code:

    void GetSomeData(char* buffer)
    {
        // put some data in buffer
    }

    int main()
    {
         char buffer[1024];
         while(1)
         {
              GetSomeData(buffer);
              // do something with the data
         }
         return 0;
    }

Would I gain any performance if I declared buffer[1024] globally?

I ran some tests on unix via the time command and there are virtually no differences between the execution times.

But I&#39;m not really convinced...

In theory should this change make a difference?

Is accessing data in the heap faster than from the stack?

Suppose that I define some class:

    class Pixel {
        public:
          Pixel(){ x=0; y=0;};
          int x;
          int y;
    }

Then write some code using it. Why would I do the following?

    Pixel p;
    p.x = 2;
    p.y = 5;

Coming from a Java world I always write:

    Pixel* p = new Pixel();
    p-&gt;x = 2;
    p-&gt;y = 5;

They basically do the same thing, right?
One is on the stack while the other is on the heap, so I&#39;ll have to delete it later on. Is there any fundamental difference between the two? Why should I prefer one over the other?


Why not use pointers for everything in C++?

I am curious to know what happens when the stack and the heap collide. If anybody has encountered this, please could they explain the scenario.


What Happens When Stack and Heap Collide

The following code creates an object on the stack:

    Object o;

When creating an object on the heap we can use:

    Object* o;
    
    o = new Object();

rather than:

    Object* o = new Object();

When we split the heap object-creation over two lines and call the constructor on the second line (`o = new object()`), does this mean in the first line (`Object* o`) the pointer was created on the stack? So `Object o` puts the object on the stack, whereas `Object* o` puts the pointer to a future object on the stack?

My second question involves if the two lines of code were called outside of a class. I recently read ([Global memory management in C in stack or heap?][1]) that global variables are not contained on the stack/heap but actually another part of memory? If this is the case, would `Object* o` create a pointer which would sit in this other part of the memory and it points to the heap object?


  [1]: https://stackoverflow.com/questions/1169858/global-memory-management-in-c-in-stack-or-heap

Object creation on the stack/heap?

I want to understand what is stored in the stack and heap in swift. I have a rough estimation:
Everything that you print and the memory address appears not the values, those are stored in the stack, and what is printed out as values, those are on the heap, basically according to value and reference types. Am I completely wrong? And optionally, could you provide a visual representation of the stack/heap?

Swift stack and heap understanding

I just know that the non-primitives (the objects) go on the heap, and methods go on the stack, but what about the primitive variables?

**--update**

Based on the answers, I could say the heap can have a new stack and heap for a given object? Given that the object will have primitive and reference variables..?

Do Java primitives go on the Stack or the Heap?

&gt; **Possible Duplicate:**  
&gt; [What and where are the stack and heap?](https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap)  

&lt;!-- End of automatically inserted text --&gt;

With regard to the basic concepts of memory layout in a c program, I understand the that:

 - The language uses two primary data structures **stack** and **heap**. 
 - Stack is created to store the local variables and book keeping data of subroutines 
 - Heap is created to store the dynamically allocated variables of the program
 - Heap is of variable length in nature.(Not very sure on stack) 
 - Normally it is the responsibility of the compiler/Language to request the OS to create these data structures before the execution.

### Questions ###

 - What is the initial size with which a stack/heap is created? and who decides it?
 - Wherein physical memory are they are created? I see a general description as ***&quot;Stack is created  in the top-level-address and the heap at the low-level-address&quot;*** Please elobarate this 

 



All Stack Memory Solutions on Gang of Coders

Total of 18 Stack Memory Solutions