Jump to content
  • Advertisement
Sign in to follow this  

class members, stack or heap?

This topic is 2220 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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;
}

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[quote name='Serapth' timestamp='1334627124' post='4931984']
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.
[/quote]


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!