0
\$\begingroup\$

I am reading the amazing Game Engine Architecture 3rd edition by Jason Gregory, but I have trouble understanding the singleton part, more particularly the part dealing with subsystem start/shutdown...

He presents a way to start and shutdown with a Singleton (Manager) not by implementing any constructor or destructor but using non-static methods startUp() and shutDown(). And he declares the instance manager as global before the main entry point. What I don't understand is: is the manager are really a singleton? Because it's not static and the constructor and destructor are not private...

Here is the implementation he gave for the renderManager:

class RenderManager { public: RenderManager() { // do nothing } ~RenderManager() { // do nothing } void startUp() { // start up the manager... } void shutDown() { // shut down the manager... } class PhysicsManager{ /* similar... */ }; class AnimationManager{ /* similar... */ }; class MemoryManager{ /* similar... */ }; class FileSystemManager { /* similar... */ }; // ... RenderManager PhysicsManager AnimationManager TextureManager VideoManager MemoryManager FileSystemManager // ... gRenderManager; gPhysicsManager; gAnimationManager; gTextureManager; gVideoManager; gMemoryManager; gFileSystemManager; int main(int argc, const char* argv) { // Start up engine systems in the correct order. gMemoryManager.startUp(); gFileSystemManager.startUp(); gVideoManager.startUp(); gTextureManager.startUp(); gRenderManager.startUp(); gAnimationManager.startUp(); gPhysicsManager.startUp(); // ... // Run the game. gSimulationManager.run(); // Shut everything down, in reverse order. // ... gPhysicsManager.shutDown(); gAnimationManager.shutDown(); gRenderManager.shutDown(); gFileSystemManager.shutDown(); gMemoryManager.shutDown(); return 0; } 

My question is: does the startUp method call any static method to initialize/grab the an static instance of the manager?

\$\endgroup\$
5
  • \$\begingroup\$ A common approach is to use a static property of a class to indicate if an instance exists (eg a pointer to a constructed instance). The "constructor" would set this property if not already set, or throw and error. You ask "... really a singleton?" In the given code, no it is not a singleton as nothing is stopping the code (compile or runtime) from creating more than one instance of RenderManager \$\endgroup\$ Commented Apr 23, 2024 at 2:38
  • \$\begingroup\$ wouldn't the constructor and the destructor already act as a startup/shutdown? \$\endgroup\$ Commented Apr 23, 2024 at 7:03
  • \$\begingroup\$ @Blindman67 The author explicitly avoid static class member in its manager to avoid random construction/destruction of the manager before compilation process, that's why I don't understand .... \$\endgroup\$ Commented Apr 23, 2024 at 8:38
  • \$\begingroup\$ @Raildex If the developer does not want to have dynamic allocation of memory for their managers (i.e. not using "new", which would be another way to control what gets initialized when), they would need to be very careful of the declaration order of the members in the the owning class because that's the order in which they are constructed in c++. This removes the option to rely on a constructor/destructor to initialized the managers and so it is presumably why they use startUp and shutDown methods. \$\endgroup\$ Commented Apr 30, 2024 at 15:54
  • \$\begingroup\$ @BenzaitSofiane it's not very possible to determine when the static object will be initialized. Here they are probably global instances, the objects will probably be created in a "random" order, but having the startUp/shutDown methods enforces the order of initialization/destruction. \$\endgroup\$ Commented Apr 30, 2024 at 15:58

1 Answer 1

1
\$\begingroup\$

No, technically this is not a Singleton according to the Gang of Four definition. There is no static method for obtaining the singleton instance, no hidden instantiation of that instance on first access and nothing that prevents or even discourages multi-instantiation.

However, in this example it is conceptually used as if it were a singleton. While it would be technically possible to create more than one RenderManager, the code only initializes a single one (which appears to be a global variable), and treats it as "the" RenderManager for the whole application.

Whether a global object is better or worse than making it a "real" singleton, or if either pattern is even a good idea at all, are a matter of debate.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.