-1

I was looking through some open source application and I noticed that the main.cpp file look something like this

...
int main()
{
    Application *app = new Application;
    delete app; 
    return 0;
}

basically the application object which represent the whole logic of the actual application is allocated on the heap, but the problem is that inside some other files that are a part of the application like Window.h or event.h to name some, there is some heap allocation going on, for example the event.h stores events in a Queue using new pointers...

and my question is: if the whole application is running on the heap, what is the point of heap allocations, does it make any difference ?

and why do a lot of applications and mostly games do this move (allocating the main "entry object" on the heap) ?

thanks!

trincot
  • 317,000
  • 35
  • 244
  • 286
Ronald joe
  • 339
  • 2
  • 9
  • To break things down: 1) "the whole logic of the actual application is allocated on the heap..." So if there's anything being done at all, then it's starting from "Application's" constructor. OK. So what? 2) "inside some other files that are a part of the application like Window.h or event.h..." Typically, headers are exclusively compile-time artifacts. 3) "if the whole application is running on the heap, what is the point of heap allocations" This is complete non-sequiter :( – paulsm4 Sep 23 '20 at 01:12
  • 1
    So why choose "heap" vs. "stack"? Often, one chooses dynamic heap allocation to control the lifetime of an object. For example, to create an object inside a function, but use it outside, in other functions. Another use case might be limited resources: allocate from the heap so as not to max out your stack. "Performance" might be yet another concern . Here's a good summary: https://www.geeksforgeeks.org/stack-vs-heap-memory-allocation/ – paulsm4 Sep 23 '20 at 01:17
  • Just because the `Application` is created dynamically doesn't negate that it likely needs to create other things dynamically, not statically. An event queue is one example of that, since events are not received until runtime and the `Application` may want to queue them for delayed processing. Creating UI elements using class wrappers would be another example, since a UI would have to be created dynamically at run-time, not statically at compile-time. There are lots of reasons why dynamic memory would be desirable, regardless of the main `Application` being created dynamically or not – Remy Lebeau Sep 23 '20 at 01:17
  • @RemyLebeau but isn't those other things already stored in the heap ? since they are a part of the heap allocated Application – Ronald joe Sep 23 '20 at 01:20
  • 1
    @Ronaldjoe Only members of the `Application` class would be stored in the memory of the `Application` object itself, whether that be created on the heap or the stack. Other things that are defined outside of the class would be handled separately. Things the `Application` creates dynamically for itself to accomplish its job at runtime. Think of a `std::vector` for example. Adding elements to a `vector` at runtime doesn't change the `std::vector` class itself, the elements are not stored in the memory of the `vector` object itself. The data is stored elsewhere in memory that the vector manages. – Remy Lebeau Sep 23 '20 at 01:24
  • @RemyLebeau Apologies if I'm annoying you but please bare with me for a moment, I do understand what you are saying but let's say that application is heap allocated, this mean that all of its members are heap allocated as well, so let's say EventHandler is a member of application hence it is allocated on the heap, so after all of this what about the members of the EventHandler object ? how are they treated in memory ? – Ronald joe Sep 23 '20 at 01:29
  • *Direct members* of a given type are defined at compile-time and are stored in the memory block of an instance of that type. So, if the `Application` class has an `EventHandler` member, that member is part of the `Application`'s memory. If an `Application` object is created on the stack, its `EventHandler` member is on the stack. If an `Application` object is created on the heap, its `EventHandler` member is on the heap. Same with the `EventHandler`'s members. And so on. But if any of those objects `new` extra data at runtime, that has nothing to do with the memory of the objects themselves. – Remy Lebeau Sep 23 '20 at 01:36
  • 1
    I'm not going to try to cover describing the complexities of object memory layout in comments. This should be covered by just about any [decent C++ book](https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list). – Remy Lebeau Sep 23 '20 at 01:41

1 Answers1

0

Is not a matter of heap allocation, in that case main() is only place where the real application starts. if you develop a graphical application, that have several classes you need something more complex than just main(). the most used way is develop a class that have capability to handle UI, Threads, init other classes, handle memory etc... usually programmer call that class "Application".