Sign in to follow this  
Tradone

Ever Since I learned pointers

Recommended Posts

Ever since I learned how to use pointers, I declare all my variables in the heap, rather in the stack. Is this generally a good idea? I mean, what would be the rule of thumb to decide whether I should declare in the heap rather than the stack? and there seems to be a difference between the free store and the heap. I thought there were the same things.

Share this post


Link to post
Share on other sites
normally things on the heap (ie. the use of pointers) occur when you are moving large variables (such as a class or struct) through functions or when you need to create an object at runtime (ie. in the middle of running your program) and it will be removed, moved, or destroyed during runtime.

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
normally things on the heap (ie. the use of pointers) occur when you are moving large variables (such as a class or struct) through functions or when you need to create an object at runtime (ie. in the middle of running your program) and it will be removed, moved, or destroyed during runtime.


Then I would safely assume that most big/modern projects will most definately use heap memory.

Share this post


Link to post
Share on other sites
anything that does not need to remain after the end of the scope, and which is not humongous in size should be put on the stack.

it is much more expensive to call new / delete than it is to put something on the stack (which has zero overhead).

Share this post


Link to post
Share on other sites
Quote:
Original post by Tradone
Quote:
Original post by Alpha_ProgDes
normally things on the heap (ie. the use of pointers) occur when you are moving large variables (such as a class or struct) through functions or when you need to create an object at runtime (ie. in the middle of running your program) and it will be removed, moved, or destroyed during runtime.


Then I would safely assume that most big/modern projects will most definately use heap memory.

You assume very correctly, but not everything is put on the heap. So don't go pointer crazy [smile]. Safest thing at this point is to make some code that works, post it on the boards, and let one of the senior members (ie. not me [smile]) point out improvements or rip it to shreds [grin]

Share this post


Link to post
Share on other sites
Not for everything...

int* i = new int(27);

try{
while(*i--)
do_stuff();
}catch(...){
delete i;
throw;
}

delete i;

would be a bit silly compared to

int i=27;
while(i--)
do_stuff();

. [wink]

Share this post


Link to post
Share on other sites
General rules of thumb - use the stack when you can, use the heap/freestore when you must and always wrap pointers in stack allocated RAII wrappers (i.e. std::vector implicitly wraps operator new[], std::auto_ptr and boost::shared_ptr explicitly wrap operator new).

Σnigma

Share this post


Link to post
Share on other sites
Thank you for all the replies.

Well, I have a class, Config as the parent class and have Path and Data as the child. But it seems like Path doesn't necessarily need to be declared it in the heap.

However if I declare Path on the stack I would have to call member functions like this : pathInstance.Get(); while dataInstance->Get();

and just makes things hell lot confusing.
and wanted some advice...
Sorry I should have explained this scenario in advance.

Edit:
As Enigma suggests, I should declare path on the stack, but it may be harder to maintain. ( I mean it's not that hard ). So I guess this is where

codemaintainability vs. performance

is an issue?

Share this post


Link to post
Share on other sites
Quote:
Original post by Tradone
However if I declare Path on the stack I would have to call member functions like this : pathInstance.Get(); while dataInstance->Get();
Using stack vs heap makes no difference whether you have to call member functions or not. In fact it can make it simpler on the stack because you can use . instead of ->

Share this post


Link to post
Share on other sites
Quote:
Original post by MrEvil
Not for everything...

int* i = new int(27);

try{
while(*i--)
do_stuff();
}catch(...){
delete i;
throw;
}

delete i;

would be a bit silly compared to

int i=27;
while(i--)
do_stuff();

. [wink]


It'd be silly compared to:

std::auto_ptr< int > i ( new int( 27 ) );
while ((*i)--)
do_stuff();


As well. But at least this version is only silly compared to the stack version with regards to the needless heap-allocation of the variable.

OP: Prefer the stack unless you have something long lived, or the API you're using gives you a pointer to work with. If you havn't allready, learn about smart pointers - they can automate a bunch of repetitious code (see the first quoted code block above) into something far more managable. I highly recommend the Boost C++ Libraries, specifically the Boost Smart Pointers Library for this discussion. Might want to check out Loki as well.

Share this post


Link to post
Share on other sites
Quote:
Original post by pcxmac
stack is like ram, heap is like virtual memory (hard drive).
(:-

You should look into those terms a bit, as you seem to be confused about a couple of things.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tradone
and there seems to be a difference between the free store and the heap. I thought there were the same things.


Free store is the general term. "The heap" refers to a specific way the free store can be implemented. People refer to "the heap" when they should talk about free store for mostly historical reasons. And then, there's "the arena" ...

Quote:
Original post by pcxmac
stack is like ram, heap is like virtual memory (hard drive).


Not at all, no.

Share this post


Link to post
Share on other sites
There is never any reason to declare basic types (ints, booleans, doubles, chars) on the heap. After that, things get a bit language specific. Java requires using the heap, C++ doesn't. But Java has garbage collection. C++ doesn't.

In general, when working with C++, try to declare everything you can on the stack, because it is MUCH harder to make a mistake. If you make a game which allocates a large array when you start a game -- things get UGLY if you forget to free it. You won't notice anything wrong when you run the program the first time, but if you play your game long enough, it is likely it will eventually run out of heap memory and crash. This is why Windows98 is famous for the Blue Screen of Death.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Tac-Tics
There is never any reason to declare basic types (ints, booleans, doubles, chars) on the heap.

There is a reason: if a basic type has to live over the end of a scope

Share this post


Link to post
Share on other sites
Quote:
Original post by pcxmac
Is the free store resident inside the process or outside?


"Free store" is a generic term that covers both in-process and out-process memory. If you use, for example, shmalloc() to allocate a chunk of shared memory, it is still said to come from the free store, just as if you had used malloc(), LocalAlloc(), GlobalAlloc(), VirtualAlloc(), HeapAlloc(), mmap() ...

In C++, new is said to allocate from the free store (while malloc() is generally said to allocate from "the heap") because new's behaviour can be modified on a global or class-by-class basis via overloading. So there is now way to tell, a priori, where the memory comes from; in fact, you can even use new to create objects in a chunk of memory that actually comes from the stack...

Share this post


Link to post
Share on other sites
Quote:
Original post by Tac-Tics
In general, when working with C++, try to declare everything you can on the stack, because it is MUCH harder to make a mistake. If you make a game which allocates a large array when you start a game -- things get UGLY if you forget to free it. You won't notice anything wrong when you run the program the first time, but if you play your game long enough, it is likely it will eventually run out of heap memory and crash. This is why Windows98 is famous for the Blue Screen of Death.


Wow! Did not know that. That was really useful information, didn't know that those blue screen were due to poor memory allocation. But, doesn't the memory get freed after the application has run?

and another question, okay, let's say that I messed up and forgot to free memory that was allocated in the heap in the beginning. So there was a memory leakage. Is there a way to monitor my free storage status both on windows and un*x based?

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
malloc(), LocalAlloc(), GlobalAlloc(), VirtualAlloc(), HeapAlloc(), mmap() ...


Yikes, looks like I need to spend some time in wikipedia. Don't know any of these!

Share this post


Link to post
Share on other sites

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