You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I personally think Cleanup should be a protected member function but not be called from the destructor, instead of being private, which would also be an alternative. Same way a constructor doesn't automatically call Initialize; the caller might want to manage resources differently and keep the Application object alive but already call Destroy or Cleanup. In that case, it's might be beneficial for the destructor to call Cleanup only if the caller hasn't done it already, or call it automatically at the end of the Run function. Another idea would be to use a syntax similar to this entirely:
This does add a bit of boilerplate code but it ultimately gives a bit more control and can be a good concept to deliver to readers who are not yet familiar with C++ or programming in general. In my own application I even give the caller the responsibility of handling the frame loop and calling rapi->draw() each frame.
I believe that was my initial intention, to call Cleanup in App::Run() after the gameloop, it is protected already (imho) (if not then yes it should be protected virtual)
That would render the dtor useless and we could technically remove it - unless c++ works differently again
The destructor can be simply replaced with the following, as unique_ptrs and ComPtrs will automatically destroy their underlying object in the default destructor.
Activity
[-]Project: Check deconstructor(chain) in all projects[/-][+]Check deconstructor(chain) in all projects[/+]JuanDiegoMontoya commentedon Mar 29, 2022
This destructor should be sufficient for the derived application classes:
I removed all
_member.Reset();calls and theApplication::Cleanup();call at the end (the base class calls it already in its destructor).spnda commentedon Mar 29, 2022
I personally think
Cleanupshould be a protected member function but not be called from the destructor, instead of being private, which would also be an alternative. Same way a constructor doesn't automatically callInitialize; the caller might want to manage resources differently and keep theApplicationobject alive but already callDestroyorCleanup. In that case, it's might be beneficial for the destructor to callCleanuponly if the caller hasn't done it already, or call it automatically at the end of theRunfunction. Another idea would be to use a syntax similar to this entirely:This does add a bit of boilerplate code but it ultimately gives a bit more control and can be a good concept to deliver to readers who are not yet familiar with C++ or programming in general. In my own application I even give the caller the responsibility of handling the frame loop and calling
rapi->draw()each frame.deccer commentedon Mar 29, 2022
I believe that was my initial intention, to call Cleanup in App::Run() after the gameloop, it is protected already (imho) (if not then yes it should be protected virtual)
That would render the dtor useless and we could technically remove it - unless c++ works differently again
spnda commentedon Mar 29, 2022
The destructor can be simply replaced with the following, as
unique_ptrs andComPtrs will automatically destroy their underlying object in the default destructor.Marking the
~Applicationvirtual will also allow any derived class to override it and implement a custom destructor, if required.[-]Check deconstructor(chain) in all projects[/-][+]Update deconstructor(chain) in all projects[/+]