Jump to content

  • Log In with Google      Sign In   
  • Create Account


class members, stack or heap?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Tdawg30   Members   -  Reputation: 172

Like
0Likes
Like

Posted 16 April 2012 - 04:27 PM

Just a quick questions regarding class members being on the stack or heap.

For example say I have:

Class Foo
{
public:
	 Foo(int someNum);
private:
	  int x;
};
Foo::Foo(int someNum)
{
	 x = someNum;
}

which I then use later in my program:

int main()
{
	  Foo x(10);	 //x object is put onto the stack
	  Foo* y = new Foo(10);	//y points to a foo object on heap
	  return 0;
}

Would the member variables of object pointed to by y be on the stack? or heap? Do I even need to concern myself with this sort of detail?
Thanks.

Sponsor:

#2 SimonForsman   Crossbones+   -  Reputation: 5753

Like
0Likes
Like

Posted 16 April 2012 - 04:46 PM

Just a quick questions regarding class members being on the stack or heap.

For example say I have:

Class Foo
{
public:
	 Foo(int someNum);
private:
	  int x;
};
Foo::Foo(int someNum)
{
	 x = someNum;
}

which I then use later in my program:

int main()
{
	  Foo x(10);	 //x object is put onto the stack
	  Foo* y = new Foo(10);	//y points to a foo object on heap
	  return 0;
}

Would the member variables of object pointed to by y be on the stack? or heap? Do I even need to concern myself with this sort of detail?
Thanks.


It will be on the heap. (the only thing that is on the stack is the pointer itself)
I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#3 Tdawg30   Members   -  Reputation: 172

Like
0Likes
Like

Posted 16 April 2012 - 04:47 PM

Thank you!

#4 Serapth   Crossbones+   -  Reputation: 5179

Like
0Likes
Like

Posted 16 April 2012 - 07:45 PM

Basically, if it's new'd, it's on the heap. If it's not, it is on the stack ( unless a global or static ).


It is of some importance, as a) the stack is actually pretty small, often only 1MB in size ( platform dependant ), so if yours is a large datatype, or you have a LOT of whatever you are allocating, a stack overflow isn't hard to cause. On the flipside, something that is on the stack is (generally) more optimizable, as the compiler knows in advanced when it will be disposed. For most practical purposes though, this isn't very important day to day. If in doubt, heap it.

#5 Jode   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 April 2012 - 08:07 AM

When you are dealing with large amounts of data (like classes), you almost always want it on the heap. As previously mentioned, the stack is rather small, and putting a whole bunch of data on it could easily cause it to overflow. The heap, however, is much larger, and therefore better for classes, structs, etc. Just make sure you always deallocate: the stack does that for you, the heap does not.

int main() {
int x = new int;
//Use the variable
delete x; //Deallocate now that your done
return 0;
}

Hobbyist game developer, game designer, and gamer.

#6 Tdawg30   Members   -  Reputation: 172

Like
0Likes
Like

Posted 17 April 2012 - 11:33 AM

Thank you for your responses,

That was my general concern I wasn't sure if I would need to explicitly create member variables on the heap ie. int x = new int(10), or would it happen automatically if the class itself was allocated on the heap. It is clear now thanks!

#7 Trienco   Crossbones+   -  Reputation: 2050

Like
0Likes
Like

Posted 17 April 2012 - 09:55 PM

Just to point it out again.. your object IS it's members. You don't have virtual functions that would add invisible overhead, so all your object "physically" consists of is a single int lying around in memory. So it simply wouldn't be possible for the object to be in a different place than its members, because they are the same thing.
f@dzhttp://festini.device-zero.de

#8 NightCreature83   Crossbones+   -  Reputation: 2670

Like
0Likes
Like

Posted 18 April 2012 - 02:17 AM

Basically, if it's new'd, it's on the heap. If it's not, it is on the stack ( unless a global or static ).


It is of some importance, as a) the stack is actually pretty small, often only 1MB in size ( platform dependant ), so if yours is a large datatype, or you have a LOT of whatever you are allocating, a stack overflow isn't hard to cause. On the flipside, something that is on the stack is (generally) more optimizable, as the compiler knows in advanced when it will be disposed. For most practical purposes though, this isn't very important day to day. If in doubt, heap it.

Stack and heap size are actually compile flag dependant, but by default in VSC++ these are set to 1MB.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#9 Serapth   Crossbones+   -  Reputation: 5179

Like
0Likes
Like

Posted 18 April 2012 - 06:23 AM


Basically, if it's new'd, it's on the heap. If it's not, it is on the stack ( unless a global or static ).


It is of some importance, as a) the stack is actually pretty small, often only 1MB in size ( platform dependant ), so if yours is a large datatype, or you have a LOT of whatever you are allocating, a stack overflow isn't hard to cause. On the flipside, something that is on the stack is (generally) more optimizable, as the compiler knows in advanced when it will be disposed. For most practical purposes though, this isn't very important day to day. If in doubt, heap it.

Stack and heap size are actually compile flag dependant, but by default in VSC++ these are set to 1MB.



This is true of Windows binaries, but not true of Linux binaries, while on MacOS the default stack is 8MB and can be set at link or at runtime. Of course, each thread you create can have it's own stack, and they can be determined programmatically.

So it really depends on the platform you are running on.

#10 FlyingDutchman   Members   -  Reputation: 207

Like
0Likes
Like

Posted 23 April 2012 - 12:26 AM

- sry wrong edit

I open sourced my C++/iOS OpenGL 2D RPG engine :-)


See my blog: (Tutorials and GameDev)

http://howtomakeitin....wordpress.com/


#11 Krohm   Crossbones+   -  Reputation: 2960

Like
0Likes
Like

Posted 23 April 2012 - 01:30 AM


int main() {

int x = new int;

//Use the variable

delete x; //Deallocate now that your done

return 0;

}

I just feel the need to point out this is strongly discouraged. Modern C++ is not so easy. Use auto_ptr or everything else ensuring proper release in case of exception. There's no guarantee, in general, the code will reach the delete call. It's also worth noticing OP forgot a pointer declaration: the above code won't compile, but I take for granted that was just a typo.

#12 FlyingDutchman   Members   -  Reputation: 207

Like
0Likes
Like

Posted 23 April 2012 - 02:06 AM

Hey, the answer to your question is fairly easy, just think about how the memory is layed out. When you have a class point and it has two member variables x and y like this:

class point {
public:
float x_;
float y_;
};

than the memory footprint is 8 byte on a 32 bit system. 2*float.

Stack:

int main()
{
point p;
int x = p.x_;
}

First, the stack pointer decrements by 8 byte (sizeof(point)) . When you refer than to x_, the assembly just takes the baseadress of p, inrements it by the offset 8 and puts that address in a register to be able to do the assigment to local x. Than it will decrement back to the old position and do the assignment.

Heap:

int main
{
point *p = new point;

int x = p->x_;

delete p;
}

What happens here is, that in the first line, the compiler will increment the stack pointer by 4 byte (1 * sizeof(point*)). Than new will find us a free address in the heap space (higher memory address space than the stack) will flag it as taken and return the address which gets stored in the 4 bytes from *p.

When we access this thingy now, assembly will look whats written in *p .This process is dereferencing. If there is a valid value it will jump to the memory address which is stored there, will increment by 8 and put the value there in a register. It will than jump back and assign it to x. :-) We could discuss now if heap access is slower than stack access :-)

If there is anything wrong or incorrect i would appreciate it if people could explain better :-)

Note: It will be different when there is a vtable :-)

I open sourced my C++/iOS OpenGL 2D RPG engine :-)


See my blog: (Tutorials and GameDev)

http://howtomakeitin....wordpress.com/





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS