Developers scarcely need to care about where the variable is on stack or on heap, right?
Right. The technique chosen for the storage is an implementation detail of the runtime.
I note that you've omitted registers as a possible choice for storage. Lots of variables are enregistered, so they go on neither the stack nor the heap.
The better way to think of it is that there is short term storage and long term storage.
Is there any quick and straightforward way to demonstrate that a variable is stored on stack or on heap?
Attempt to compute the lifetime of the variable. If you can do so easily, and the lifetime is less than or equal to the duration of the method activation which created it, then it is likely on the short term pool. If not, it's likely on the long-term pool.
In C++, I can get a variable's memory address and view its value stored in stack or heap memory by VS memory window.
Doing so with the & operator can change where the variable is stored! If you take the address of a variable then it cannot be enregistered because registers don't have addresses. A technique which changes what it attempts to describe is an unreliable technique.
Also, you are perhaps forgetting that in C++ the stack and the heap are not the only possible storage locations.
For example, if I tell someone the reference type variables are stored on heap or the local value type variable on stack(right?). How can I show that explicitly?
Since those statements are false you cannot show them at all. It is simply false that references always go on the heap and that local variables of value type go on the stack. Example:
void M()
{
string s = "";
...
The empty string is on the long term storage pool, but the empty string isn't stored in s in the first place. A reference to the empty string is stored in s. That reference can be put in the short term pool.
Remember, the actual referants of a reference type do not go in variables at all. Variables of reference type hold references -- that's why they're called reference types.
Now, a field of a reference type is a variable, and that variable does not have a known lifetime, so that variable must go on the long term storage pool:
class C { public int x; }
...
C M() { C c = new C(); return c; }
x is a variable of value type but because it is a field belonging to a reference type, it must be on the long-term pool. c is a variable of reference type so it holds a reference; the lifetime of the variable c is short, so c goes on the short-term pool. Again do not confuse the reference with the thing being referred to.
Example:
Action<int> M()
{
int x = 123;
return y => { x = y; Console.WriteLine(x); };
}
Local variable x is of value type but you cannot compute its lifetime and therefore it must be on the long term storage pool.
Since your statement that variables of reference type go on the heap and local variables of value type go on the stack is false, there is no way to demonstrate its truth.
