Sign in to follow this  

Pointers and Objects question

This topic is 4354 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

I'm wondering if there's any difference between creating an instance of your object on the heap - and thus all the variables in the object are automatically put on the heap too which means you don't need to worry about creating / deleting them. Or is there an advantage to creating your object on the stack and having your object create all of it's variables on the heap instead. Also, if an object is created on the heap, are object instances within the object also automatically created on the heap too? Thanks Matt

Share this post


Link to post
Share on other sites
stack is typically limited to 2MB per application or so. heap is the entire amount of ram and virtual memory that the system has.

generally, if it's big and persistent outside of the local stack frame (i.e. persists outside of a function call) then you go heap. only small things should inhabit the stack.

if you "new" an object onto the heap then all it's data are also on the heap. if you have a stack object that new's stuff, then the object is on the stack and the "new"'d stuff is on the heap. basically, "new" == heap.

-me

Share this post


Link to post
Share on other sites
To my mind, the main difference between heap and stack allocation of objects in C++ is programmatic flow control. Objects that you are just going to use during a function, and that should then go away I think should be stack-allocated unless there's a compelling reason to do otherwise. Because stack-allocated objects will be deallocated no matter how execution leaves the function.

If you heap allocate, you have to set up a finally block to ensure that the memory is deleted in the event of an exception.

Any variable-length data within a stack-allocated object, like the buffer associated with an std::vector or whatever, will be on the heap. The point here is that when the containing object goes out of scope, its destructor will get called and then everything is cool.

There is a class in MFC called, like CWaitCursor or something along those lines. Its a fairly clever little class that contains a static count member variable. When you want an Hourglass, you declare one of these on the stack and then forget about it. In its constructor it will increment the static counter. Then its destructor will decrement it. When the counter is 0, it sets the cursort to default. When its greater than zero, it sets it to an hourglass.

It works good because the counter will be decremented no matter how execution leaves the function. Properly deployed and consistantly used, it ensures you'll never get the mousepointer stuck in hourglass mode. That's an example of a class designed to be instantiated on the stack.

Share this post


Link to post
Share on other sites
"...only small things should inhabit the stack."

So is there any point in creating built-in types ( int , float etc ) on the heap? By my understanding of whay you've said It'd be better to keep them on the stack which'll make your code easier to read and write.

And is either having your object on the heap or having just it's variables on the heap better?

I was thinking that having the object on the heap would be better because you could code your object without having to worry about deleting all your variables and it'd make the code within your object easier to read.

Thanks for the replies

Matt

Share this post


Link to post
Share on other sites
Use the heap when you have to (you will know because it "doesn't work" on the stack); use the stack when you can. The common reasons for using the heap are

(a) some data has to outlive its scope, and a static variable doesn't cut it for whatever reason

(b) you don't know until run-time (i.e. it depends on user input or the contents of a file) how many things there will be in some array

(c) (related) you are using polymorphism, and you don't know until runtime (hence the usefulness of polymorphism) exactly which derived object you will create.

Share this post


Link to post
Share on other sites

This topic is 4354 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this