Stack/Heap knowing when to allocate to what
Hi, I am currently learning about stack/heap, and reading some posts it seems that most say, you use the stack if you know how much data needs allocated, and the heap when you dont know. But being newer to programming, I am unsure, when I would and would not know about the amount of data.
So for data amount I would not know, would that be something like a database, or such, since it can grow in size?
And for knowing how much data, would that simply be a local variable?
Also while I am asking, to access the data on the heap, can that only be done with pointers?
if anyone can answer these questions, i would greatly appreciate it, Thanks
So for data amount I would not know, would that be something like a database, or such, since it can grow in size?
And for knowing how much data, would that simply be a local variable?
Also while I am asking, to access the data on the heap, can that only be done with pointers?
if anyone can answer these questions, i would greatly appreciate it, Thanks
databases are so large they mostly live on fast hard drives with very efficient disk operations. That is another story. If you don't know how much spew is coming back from a DB query program, that will go on the heap, sure.
But yes, the heap is for data that is too big for the stack (the os gives you a small amount of memory for your program, and its fixed size, and if you exceed it you will crash, and its used for local variables AND pushing the cpu registers and such when functions are called; one way to exceed stack memory is a run-away recursive program that calls functions too many times). I tend to look at the heap if I am making anything that over a MB or so, eg if you get an itch to make an array to hold the contents of a gigabyte sized file, better use the heap (and yea, that means a pointer or a container that uses pointers like vector).
Not sure what you mean by knowing how much. You can mentally add up what memory your routines are using (is this what you are asking?), roughly, or you can run it an look at the numbers (top/taskmanager is good enough for rough values). Local variables that are not arrays are going to be microscopic... we live in a gigabyte world and they are 4, 8, 10 or so bytes a pop for the most part. An array is a multiplier, so array[10] is 10 times the 4 or 8 or whatever bytes, not a big deal. An array[10000000] is a big deal, better move it. Its a bit of common sense, not any hard rules here.
there are other ways to access the heap, but most involve a pointer, either directly or indirectly (eg <string> hits the heap, <vector> does too, etc, indirectly). Some embedded or oddball computers may allow direct access of some flavor, but most normal work, its going to be via pointers.
I would say, don't sweat this too much. Anything huge, put it on the heap via a c++ container. Anything small, let it do what it does. Most of the time, exceeding the stack is done by being careless. Keep in the back of your mind when you are dealing with fat objects or lots of data and put that on the heap (again, using containers most of the time) and youll be fine.
But yes, the heap is for data that is too big for the stack (the os gives you a small amount of memory for your program, and its fixed size, and if you exceed it you will crash, and its used for local variables AND pushing the cpu registers and such when functions are called; one way to exceed stack memory is a run-away recursive program that calls functions too many times). I tend to look at the heap if I am making anything that over a MB or so, eg if you get an itch to make an array to hold the contents of a gigabyte sized file, better use the heap (and yea, that means a pointer or a container that uses pointers like vector).
Not sure what you mean by knowing how much. You can mentally add up what memory your routines are using (is this what you are asking?), roughly, or you can run it an look at the numbers (top/taskmanager is good enough for rough values). Local variables that are not arrays are going to be microscopic... we live in a gigabyte world and they are 4, 8, 10 or so bytes a pop for the most part. An array is a multiplier, so array[10] is 10 times the 4 or 8 or whatever bytes, not a big deal. An array[10000000] is a big deal, better move it. Its a bit of common sense, not any hard rules here.
there are other ways to access the heap, but most involve a pointer, either directly or indirectly (eg <string> hits the heap, <vector> does too, etc, indirectly). Some embedded or oddball computers may allow direct access of some flavor, but most normal work, its going to be via pointers.
I would say, don't sweat this too much. Anything huge, put it on the heap via a c++ container. Anything small, let it do what it does. Most of the time, exceeding the stack is done by being careless. Keep in the back of your mind when you are dealing with fat objects or lots of data and put that on the heap (again, using containers most of the time) and youll be fine.
Last edited on
The big difference between the stack and the heap is the allocation of memory. On the stack, allocation is just one CPU instruction. Whereas on the heap, it's a heavier operation. So a small tip, you should always try to allocate on the stack whenever possible because it's faster.
If you don't know the amount of data you want to allocate at compile time (perhaps you have a database that could grow or shrink in size as needed), then you would dynamically allocate memory on the heap but be sure to free the memory once you're done using it because the heap does not automatically do so. When you allocate memory with the
When you allocate memory on the heap, you usually have a pointer on the stack that points to that memory. Therefore, the only way you can access the data on the heap would be through that pointer.
If you don't know the amount of data you want to allocate at compile time (perhaps you have a database that could grow or shrink in size as needed), then you would dynamically allocate memory on the heap but be sure to free the memory once you're done using it because the heap does not automatically do so. When you allocate memory with the
new keyword, a function named malloc() will be called which usually have to call the underlying operating system to allocate memory on the heap for you. If you're curious, check this article to learn more about malloc(): https://computer.howstuffworks.com/c29.htmWhen you allocate memory on the heap, you usually have a pointer on the stack that points to that memory. Therefore, the only way you can access the data on the heap would be through that pointer.
Hi,
One can achieve a lot by just using the STL, and don't worry about manual memory management at all. As in, generally: don't use
Using the stack is fine if:
The object is not too large and there are not many of them, or it goes out of scope quickly, this is the case for local variables;
There is only ever going to be one of these objects, and it isn't too large.
Otherwise put the data into an STL container.
Remember that the stack is usually quite small, it might only be 1MB.
So when to use
If you have invented a new type of container and are writing a library for it, then you might need to allocate and delete memory manually. One example is if one writes their own implementation of a list, there is a need to
Also consider using a memory pool.
Just remember the big problem with
One can achieve a lot by just using the STL, and don't worry about manual memory management at all. As in, generally: don't use
new and delete at all, nor malloc and free. More about when one does need to use new below. The STL containers use RAII principles and store their data on the heap internally, other classes like std::string do this too.Using the stack is fine if:
The object is not too large and there are not many of them, or it goes out of scope quickly, this is the case for local variables;
There is only ever going to be one of these objects, and it isn't too large.
Otherwise put the data into an STL container.
Remember that the stack is usually quite small, it might only be 1MB.
So when to use
new?If you have invented a new type of container and are writing a library for it, then you might need to allocate and delete memory manually. One example is if one writes their own implementation of a list, there is a need to
new each node.Also consider using a memory pool.
Just remember the big problem with
new and delete is that if an exception is thrown, neither the destructor nor the delete are reached, so there is a memory leak.
Topic archived. No new replies allowed.