Do memberfunctions put their local data on the stack?

Question

0.00/5 (No votes)

See more:

I have a simple question about the scope of a object and the scope inside of the member functions.

Computer memory visible for a program is basicly devided in two parts:
1. the stack
2. the heap

The stack act like pile a dishes: You put things on top of it and remove things in reverse order.
The heap is like a cabinet with drawers. You have to look for an empty one to put a thing in.
A drawer can be full as long as the program runs.

Here i have a scope:

C++

{
  MyClassType *pObjOnHeap;
  {
     MyClassType objOnStack;
     objOnStack.sayHello();
   
     pObjOnHeap = new MyClassType;
     pObjOnHeap->sayHello();
  }
  delete pObjOnHeap;
}

The objOnStack is created its data in the stack.
The pObjOnHeap is created its data in the heap.
But both theirs member-functions push and pop their local data on the stack.
Is this right?

What I have tried:

I read "The C++ Programming Language 4th edition" by Bjarne Stroustrup.

Posted 22-Nov-16 23:46pm

Theo Buys

Updated 23-Nov-16 0:58am

Richard MacCutchan

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Accepted Answer · 2016-11-23T00:58:00

Solution 1

It depends. The following sample will list the addresses of the objects and the member variables, showing where they are created:

C++

class CObject
{
public:
    void Method()
    {
        printf("\n\tIn Method\n");
        int localVar; // stack variable
        localVar = 5;
        printf("\t\tlocalVar: %p\n", &localVar);
        int* heapVar = new int[20]; // heap variable
        heapVar[1] = 100;
        printf("\t\theapVar: %p\n", heapVar);
        //delete[] heapVar; --> don't delete so next call to new will use new heap address
    }
};

int result = 0;
printf("result: %p\n", &result);
CObject localObject; // object on the stack
printf("\nlocalObject: %p\n", &localObject);
localObject.Method();

CObject* heapObject = new CObject(); // object on the heap
printf("\nheapObject: %p\n", heapObject);
heapObject->Method();

You should see the difference (in both cases) between the local variable created in Method, and the heap variable.

Posted 23-Nov-16 0:58am

Richard MacCutchan

Comments

Theo Buys 23-Nov-16 11:52am

So, the pointer heapVar is on the stack while the memory for the int[20] is on the heap. The pointer goes out of scope but the memory remains. I think that this proofs that memberfunctions of a heap allocated object are not part of that allocation but only the data and not the local data used in the member functions. The use of heapvar in the example is a kind of wild west and not part of the class data. This way the object creates memory leaks.

Richard MacCutchan 23-Nov-16 12:07pm

Yes, I did that deliberately to show that the second allocation would take a block from a different part of the heap. Whereas the stack location gets reused. The choice of using the stack or the heap really depends on the requirements of the member function. The sample above is just used to demonstrate the difference.

As with any heap allocation it is the programmer's responsibility that he/she properly disposes of allocated memory.

Theo Buys 1-Dec-16 11:10am

Now forget all about allocating objects in the member functions. Lets look only at the class variables and the supporting member functions.

1) If allocate the object of the class on the heap, then the class and its variables are on the heap but if I run a memberfunction it uses the stack for its local variables and only the heap for the class variables.

2) If create the object of the class on the stack, then the class and its variables are on the stack and if I run a memberfunction it uses the stack for both its local variables and the class variables.

3) The size of a class depends on the class variables and not the size of the memberfunctions code.

Richard MacCutchan 1-Dec-16 11:29am

1) Yes.
2) Yes.
3) Yes.
However, in 1 & 2 it is the object and its variables that are allocated on the heap or the stack; not the class. And object variables; the term class variables refers to static variables in a class definition.

Theo Buys 2-Dec-16 1:28am

yes, right! I must say:
3) The size of an object of a class depends on the class variables and not the size of the memberfunctions code.

Richard MacCutchan 2-Dec-16 3:31am

Yes because the code exists in a separate part of the activity's address space, and is not counted as part of the object. The object only consumes space in the data section of the activity. And you can have many objects of the class, but only one copy of the executable code.

Theo Buys 2-Dec-16 4:02am

Thanks!