0

Let's say I have the following program:

public class Wallet
{
    private int _money;

    public Wallet(int money)
    {
        _money = money;
    }
}

public class Person
{
    private string _name;
    private Wallet _wallet;

    public Person(string name)
    {
        _wallet = new Wallet(0);
        _name = name;
    }
}

class TestClass
{
    static void Main(string[] args)
    {
        var person = new Person("Toto");
    }
}

If I understood well:

  1. The reference to person will be stored on the stack
  2. The members held by a referenceType are stored on the heap so the mebers of Person will be stored on the heap, so _name and _wallet
  3. As _money is hold by Wallet, it would be stored on the heap too

I was wondering if actually, the reference of _wallet would be stored on the stack too, then _money and _name on the heap.

Is that correct ?

PS: Normaly I would inject Wallet but it would not be appropriate for my question.

trincot
  • 317,000
  • 35
  • 244
  • 286
Milan
  • 1,547
  • 1
  • 24
  • 47
  • 2
    Does it matter? "You should consider the question of where objects get allocated as an implementation detail. It does not matter to you exactly where the bits of an object are stored. It may matter whether an object is a reference type or a value type, but you don't have to worry about where it will be stored until you start having to optimize garbage collection behavior." https://stackoverflow.com/a/4487320/1043380 – gunr2171 May 15 '23 at 18:51
  • Wallet isn't used so why should a reference be on the stack? It should(or might) get on the stack if you call something on that instance. – Ralf May 15 '23 at 19:09
  • @Ralf Perhaps you missed what the constructor for `Person` does? – NetMage May 15 '23 at 20:16
  • @gunr2171 I wholeheartedly disagree. Sure, you don't *have to* learn about it, but wanting to know more about how anything works is a good thing, not something to be discouraged. Furthermore, it absolutely does matter. Speaking from personal experience, people who don't have a good mental image of memory and references are the ones who are surprised that `EditStringRef(ref array[0]);` doesn't do the same thing as `string str = array[0]; EditStringRef(ref str);` – Petrusion May 16 '23 at 00:19

2 Answers2

2

First of all The Stack Is An Implementation Detail, Part One (Part Two).

As for what is stored where - memory allocated to store reference types's data/info (in current CLR implementation) is stored on the heap, this includes fields (and backing fields for properties) both of value and reference types, the difference will be what is stored in the memory allocated for the object on heap (for value types it would be value itself, for reference - reference to another object on heap).

So in this case reference stored in _wallet will be on heap as the object this field references.

Read also:

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
  • 1
    "for obvious reasons stored on the heap" doesn't have to be, it can be a stack-allocated reference type (although there are no implementations in the wild at the mo). In my personal conforming implementation of .NET, objects are stored on the moon, which is made of cheese, and the logical stack is made of pizza boxes with hand-written notes. – Charlieface May 15 '23 at 20:27
  • @Charlieface improved wording a bit. Obvious reasons was coming from assumption of current CLR implementation. – Guru Stron May 15 '23 at 20:31
0

The person reference is a local variable so it goes in the call stack. An instance property like _wallet is not a local variable so it goes in the heap because it belongs to the whole class.

beautifulcoder
  • 10,832
  • 3
  • 19
  • 29