Stack vs. Heap Question, Please Help

[Nick Hounsome]

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.

This is a discussion of C# not C++.

The lifetime of an entity on the stack ALWAYS matches the defining scope. If
the entity is a reference then the lifetime of the reference matches the
defining scope even if the lifetime of the object referenced doesn't.

Stack is faster because at the end of a method it is always valid to just
alter the stackpointer by the number of bytes allocated on the stack or more
typically to load the previous frame's stack pointer. NB structs are
prohibitted from having destructors precisely because it would prevent this
use of stacks [they would have to be called exectly like C++ destructors -
It could obviously be done and it would create some interesting new
programming opportunities! Perhaps 3.0?]

In C# there is less performance benefit on allocation (as opposed to C++)
because C# just increases a pointer and leaves all the hard work to garbage
collection though even here stack is still sloghtly cheaper because there is
no locking involved as the stack is inherently local to the thread.

 

[Nick Hounsome]

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.

struct parameters and structs within methods are thread local as
(recursively) are any structs they contain directly. Everything else is
shared. You don't need to use the words stack or heap to explain this.

P.S. It is totally possible to implement a stack in a stackless
architecture - just pass a pointer to the array of arguments and allocate
frames off the heap - of course you then have a "stack" but it is a
different sort of stack and not as efficient for aloocation although the
deallocation efficiency still applies.

 

[Mattias Sjögren]

I am applying for an entry level tester job at M$ and have had

several interviews with no luck but this was the worst...

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


Mattias

 

[Jon Skeet [C# MVP]]

struct parameters and structs within methods are thread local as
(recursively) are any structs they contain directly. Everything else is
shared. You don't need to use the words stack or heap to explain this.

You don't *need* to, but it helps IMO.

(Things get a lot more complicated with anonymous methods, by the way -
variables which look local can end up being captured, and then at
different levels. All kinds of weird stuff can happen.)

P.S. It is totally possible to implement a stack in a stackless
architecture - just pass a pointer to the array of arguments and allocate
frames off the heap - of course you then have a "stack" but it is a
different sort of stack and not as efficient for aloocation although the
deallocation efficiency still applies.

Sure.

 

[Mike]

This is a discussion of C# not C++.

No, it's not.
The interviewer clearly asked, "why have a heap at all" - and C# clearly has
a heap, therefore the discussion was not about C#, but a more general one
aimed at investigating the limits the potential employee. The OP did not
even frame his question in the scope of C# - and it really doesn't make a
difference what language the answer is with respect to, but from posting
here we can assume that staying close c# terminology is a good way to answer
the OP's (and the interviewer's) question.

m