Circle is a class, not a struct, so creation of the circle goes on the heap.
(Or so as to not confuse it with the datastructure of the same same, let's
just say the "data pool".) The *reference* to that object is stored on the
stack, inside the stackframe of "main". (Note that if your struct is
*inside* a class instance, the struct is allocated on the heap with the rest
of the class...)
When you exit "main", the stack is unwould and the reference to "c" goes
away, and seeing in this case it's the sole reference to the object in the
memory pool, our circle object will deallocated when the GC finds the time
to do so. (Ignoring any clever optimizations by the compiler.)

For "c" to be allocated on the stack in c#, it would have to be a struct. In
that case, the memory stack allocation would be enough to hold all its
memebers, not just enough for a reference (in this they're the same size)
and if you passed "c" to another function (which you don't in your example)
the enitre object would get *copied* into the stack of the called fn's
stackframe, vs. just the reference to the heap (think "pointer that you
can't change") getting copied in the "class" case. Everything in c# is
passed by value, including object *references*, as long as we ignore ref/out
parameters.

So in contrast to most languages, in c# the stack vs. memory-pool descision
is not made at the point of allocation, but at the point of object (class
vs. struct) definition.

You may also want to look at "using" and "IDispose" - it combines heap
allocation with the scope-based pattern you get with stacks.

m

The sample program you gave doesn't have the right stuff to demonstrate
what Mike was talking about. Here's a similar sample that should help:

public class Circle
{
   private Point _centre;
   private double _radius;

   public Circle(Point centre, double radius)
   {
       this._centre = centre;
       this_radius = radius;
   }

   public double Radius { get { return this._radius; } }

   public bool SameSize(Circle otherCircle)
   {
       return this._radius == otherCircle._radius;
   }
}

class Test
{
   static Circle Function1()
   {
       return new Circle(new Point(0, 0), 15.0);
   }

   static bool IsFifteen(Circle c)
   {
       return c.IsSameSize(new Circle(new Point(0, 0), 15));
   }

   static void Main()
   {
       Circle aCircle = Function1();
       Console.WriteLine("Circle has radius of fifteen: {0}.",
IsFifteen(aCircle));
   }
}

So, let's look at what would happen if everything were on the stack and
there were no heap. The answer is that it would mess up object
lifetimes, so that's what we're going to examine.

The first thing Main does is call Function1. It doesn't pass any
arguments, so nothing is pushed on the stack (except return addresses
and such).

Function1 instantiates a new Circle object. So, let's say that
(contrary to the way that .NET really works) this goes on the stack,
not the heap.

Function1 now returns the Circle, which really means that it returns a
reference to the Circle object by placing that reference on the stack.
So, just before Function1 exits, the stack looks something like (top to
bottom):

a Circle object
a reference to the Circle (the return value)
return addresses and other housekeeping information

I'm not so sure about where the return value sits relative to the other
items, but you get the idea.

So, now Function1 returns. In the process, the stack is unwound. So
far, we're safe: Main has a reference to the circle in aCircle (which
is also on the stack, lower down) which points to the Circle object,
which is higher up the stack.

Now Main calls IsFifteen, passing it a reference to the Circle object,
farther up the stack. The argument, a reference, is pushed on the
stack. At this point the stack may or may not have arrived at where the
original Circle is stored, but like the shark in Jaws, it's getting
awfully close.

The first thing that IsFifteen does is allocate a new Circle that it
wants to pass to the original Circle's "SameSize" method. Well, if
passing the Circle reference to IsFifteen didn't overwrite the original
Circle, this surely did. Passing SameSize a reference to the new circle
just seals it.

So what happened? The original Circle object, allocated by Function1
and left behind on the stack, was overwritten by arguments and local
variables for other methods later on. When Function1 returned, the
stack was unwound, leaving the original Circle object high and dry, but
as Main called other methods, they ate up stack space and eventually
overwrote the Circle object. This left references to the original
Circle object pointing into the middle of... well, junk. Stack stuff
that belonged to other methods.

So, we need a heap because often objects live longer than the lifetime
of a single method call. The method returns but the object lives on (as
happened in Function1: the function ended, but the Circle object lived
on). Since the stack is re-used as methods are called, and released as
methods return, we can't use it for long-term storage of objects; it's
too volatile. We need some other place to put things whose lifetimes
don't dovetail with the lifetimes of method calls. That place is the
heap.

I was asking what sort of job was it for?

I was gobsmacked that someone would actually need to ask such a question in
any reasonable interview!

Perhaps you'd have more luck if you stop referring to your future
employer with derogatory names such as M$.

Mattias

Hi,

Personnally I think this is a very good interview question.  Memory
management is a very important topic in all programming languages and
it is important to know the potential effects of a particular
implementation approach.  Even garbage collected languages ( Java, .Net
) will perform differently depending on stack vs heap memory usage.

There are a huge range of bugs / errors that can be introduced into
software if memory management is not understood ( i.e. references to
items on the stack, memory loss, etc.. ).  I'm sure memory management
issues form a large percentage of real-world bugs.

As a very very basic guideline, if you wish to re-use something put it
in the heap, if it is only temporary put it on the stack.

RichS

Not necessarily. Assuming your entity lifetime matches the defining scope of
the stack var, this may be true - but otherwise often not.
That's why many C++ programs that are improperly using value semantics run
much faster when ported to C# -
it avoids the invocation of copy constunctors, etc., every time an instance
is passed on the stack.
Sure, this may not be a properly designed program, but it not always easy to
see where this is going to happen in complex code.

Arcticool - it seems like half the responses are for stack vs. heap
*datastructures* and half were stack vs. heap memory *allocation* responses
(mine included.) These are related but really different questions -- what
where you asking??
MichaelN's great wikipedia links are regarding the fomer, whereas given your
mention of

I'm assuming the former is what you were after.

m

<snip>

I don't know - I think that the idea of variables being on the stack or
on the heap (along with the concept of stack frames) is very important
when it comes to understanding threading, and why if two threads are
running the same method at the same time (or even a single thread
running a method recursively) they get separate local variables, but if
they access the same object on the heap, that data is shared.

Now, the low-level details of what those mean in terms of allocation
aren't terribly important IMO, but the concepts themselves are.