   Singleton inheritance?
  Hi i have base class called manager state in which all managers inherit. WHat i am trying achieve is to have only one instance of any of these managers at one time, there will be the main manager that will add the entities to other managers?class ManagerState{   virtual AddEntity(Entity *a);}class RenderManager : public ManagerState{}how do i go by making these singletons?   
RenderManager * getRenderManager() {  static RenderManager instance;  return &instance};OtherManager * getOtherManager() {  static OtherManager instance;  return &instance};// and so on...;  Before you pursue this any further, I would advise you search these forums for some of the many threads about whether Singletons are a good idea or even necessary.In particular, here and here.   ;  Heck, before even considering whether a singleton is the right idea, I'd consider whether a manager is the right idea. It would be fantastic to at least come up with a better name that more precisely defines the class's function. If you can't come up with one, that might indicate that your class is doing too much and should be broken up or that you haven't thought out your design enough.   ;  Definately read the thread's linked by rip-off, but the anti-singleton position can be summarized as following:First, the singleton pattern is prescribed to fulfill the following requirements: That the object must have global visibility and must not co-exist with any other instance of itself. Must is meant in the strictest of interpretation, you can not substitue "I want" or "It would be less typing" or "It would be more convenient if" -- it must be so.A singleton's global-ness is an artifact of it's implimentation -- if you create a singleton, it is a global. I'm not aware of singleton implimentation that is not global.A singleton's single-ness is most usually wishfull thinking and/or lazyness on the part of the programmer -- they don't need only a single instance, rather they want only a single instance. This desire on their part is motivated either by a) They believe the implimentation will be simpler if they can assume only a single instance, or b) because they believe it usefull to enforce its singleness, rather than just trusting the programmer to create and use only one, where only one is appropriate. In the case of A, it is sometimes true that an implimentation can be simplified if you don't have to worry about data interactions between two of these objects, it also tends to make the implimentation less thought-out, less engineered, less robust and less re-usable because it simply chooses to ignore that entire line of thought, rather than doing away with it. In the case of B, it is not the job of the provider to prevent self-sabotage -- that is up to the user -- the job of the provider is to mitigate unintentional mis-use.Proper justification for singleness almost always comes from an external reality -- one which cannot be engineered away in software. I and many others have said many times that it is difficult to even imagine a legitimate use of the Singleton pattern in application software, and that it's need is rare even in system-level or embedded work.Finally, there are some general cons against singletons --1) Because singletons are globals (I like to call them "Global's in sheep's clothing") all the bad things about ghaving global mutable state come along for the ride -- chiefly that it greatly increases the difficulty of reasoning about your code in the face of errors because it makes the entirety of said code implicitly dependant on that mutable state and anything that has touched it.2) Singletons are actually worse than globals because if I ever decide that it wouldn't be such a bad idea to have another or, indeed, that it might be The Rigth Thing To Do, I now have to go through all my singleton-object-touching code and undo all the plumbing that enforced its singularity. Had I just made it a simple global to begin with, I could have just created another and be done with it.3) Singletons make proper testing proceedures hard. Firstly because of the introduction of global mutable state that we discussed in 1, and secondly because it makes replacing parts of the code with dummy-instances for testing purposes difficult if not impossible.Singletons, like any pattern, are a tool. Some small tools do little harm, even if intentionally mis-used, but the singleton is not such a tool. The singleton is a powerful (and respectively dangerous) tool which has far reaching consequences which are not immediately aparent to the uninitiated -- It's like trying to hang a mirror with sledgehammer -- the likelihood that things will go wrong far outweight the chances that things will go right. The singleton is a Big Fucking Hammer (TM) that is all too often applied to the smallest of nails (or worse, when the problem calls for a different tool entirely.)   ;Quote:Original post by EzbezHeck, before even considering whether a singleton is the right idea, I'd consider whether a manager is the right idea. It would be fantastic to at least come up with a better name that more precisely defines the class's function. If you can't come up with one, that might indicate that your class is doing too much and should be broken up or that you haven't thought out your design enough.Quoted for Emphasis, this cannot be more true.From my upcoming GameDev.net article on resource management (unedited):Quote:The problem with “manager” is that the term is so ambiguous that the only way we might be able to glean some insight into what it means to “manage” is by hoping that the other words it’s attached to might lend us some context. It is for this reason that “manager” should always be avoided in names wherever a more specific option exists.