-2

I am a new comer in C++ and found that in C++, you have 2 methods to create a object: object on a stack and object on a heap.

But I am curious to know what are the pros and cons of using object on stack vs. object on heap.

In what situations, first method is preferable over the second method and vice versa?

explorer
  • 737
  • 1
  • 8
  • 23
  • 3
    Duplicate of http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap and http://stackoverflow.com/questions/10157122/object-creation-on-the-stack-heap?rq=1 and http://stackoverflow.com/questions/8781997/pointers-to-objects-in-c-whats-on-the-stack-heap?rq=1 *and* http://stackoverflow.com/questions/5836309/stack-memory-vs-heap-memory?rq=1. – kirbyfan64sos Nov 03 '15 at 23:06
  • 1
    @Vishlesh Patel There are also objects with static storage duration. I think your question is too broad.:) – Vlad from Moscow Nov 03 '15 at 23:07
  • The question is too homework. – Martin James Nov 03 '15 at 23:15
  • It is pretty simple: If your programming task can be solved solely by use of the stack - do it. If not - use the heap. In other words: If you can accomplish the task at hand solely by use of stack, it is for sure the best to do. The stack has no cons as long as you can solve your task. – Support Ukraine Nov 03 '15 at 23:32
  • _"you have 2 methods to create a object: object on a stack and object on a heap."_ Not true in the slightest. – Lightness Races in Orbit Nov 04 '15 at 00:31
  • @MartinJames hey martin....this is not a platform for any debate...n why do u care about homeworks n all...u should appreciate others who are answering...rather than finding mistakes. – explorer Nov 04 '15 at 05:00

1 Answers1

2

Objects on the stack have the really neat property that the memory that backs them is automatically freed at the end of that stack frame (e.g. when the function returns.) C++ extends this concept by also calling destructors for all stack objects whenever they fall out of scope (i.e. they're still freed in the case that an exception is thrown before the function returns.) Since this makes memory management dead simple, and memory management errors have the frustrating combination of being easy to make and hard to detect, stack allocation should be preferred whenever it is feasible.

The downside of stack-allocated objects is...well...they're deleted when the function returns. Sometimes there are legitimate reasons to want the object to live longer. In those cases, you have no choice but to allocate from the heap.

Another point to consider is that stack allocation pretty much has to be a size that is known at the time the software is compiled (but see alloca function available on some platforms.) There are a ton of real world scenarios where you won't know until the program is running how much memory you need. Take for example an address book application. If I am coding such an application, I obviously have no idea how many people the end user is going to want in their address book. The user has to tell the program this information. In this case, you need to have dynamically allocated memory, so you're again looking at heap allocation.

Evelyn Parenteau
  • 94
  • 3