   using singletons
  Hello,In a full-fledged game engine, how useful are singletons, and are they considered good practice.Just want some advice from the pro's[smile],exorcist_bob   
  I don't want to sound rude but have you searched these forums?  This question has been asked and answered a few times already.A run down from the ones I've read...The majority are along the lines of:Globals are bad, hard to debug.  A singleton is basically a global.Yet others say in some instances they're ok, like a logger but why not just make namespace protected functions, you don't NEED a class for a logger.  Not everything needs to be in a class.  Anyways in most cases a better design can get you around the "need" for a singleton.  Who says you only need one renderer, scene graph or resource manager?  I might want to load two resource managers so I can pre-load the next level...There are times when singletons are ok, but there is almost always a better solution.  But this is just my opinion.   ;  It's hard to not program using singletons everywhere for a beginning programmer. Its a natural first reaction to make a bunch of manager classes that are singletons, but pick up a book on software architecture. There are a lot of really cool programming paradigms out there that are really useful.   ;  I use them vary sparingly and usually for such things as an input system or the renderer. When considering using a singleton, think very hard if you really need to limit the class to one instance.   ;Quote:Original post by exorcist_bobhow useful are singletonsNot very.Quote:and are they considered good practice.Not really.;  The architecture of Fleurin (server).cData.cs-> public partial class cMain()cGridy.cs-> public partial class cMain()cMain.cs-> public partial class cMain()cNPC.cs-> public partial class cMain()cPacket.cs-> public partial class cMain()cPathfinding.cs-> public partial class cMain()cPhysics.cs-> public partial class cMain()cSocket.cs-> public partial class cMain()cUI.cs-> public partial class cMain()cTimer.cs-> public partial class cMain()cCommon.cs-> public class cFleurinFlags()cINI.cs-> public class cINIReader()-> public class cINIWriter()-> public class cINIAppend()Globals: LOTSLocals: LOTSScope Confusion: NONE! (via variable prefixing)   ;  @Thevenin: Umm... How does that answer the OPs question really?  You make us search google or the forums for "Fleurin" to get some obscure post about it (forth or fifth link down on google I think).Few people (not a single coder I've ever talked too or known) think globals are anything close to good programming practice.  Atleast with OO languages.Btw hope you're projects going well, looked cool.@OP: Like many have said, you can almost always find a better solution then a singleton.  There is no reason to have only one renderer, what if I want to render, using your engine, a different view to a different monitor?  Now I cannot do that easily, you've restricted me when you could just put in the documentation, "Only use one instance of this class".  If they fail to read it, it's not your problem, you're not a babysitter.  Why force someone to do something a particular way because you didn't see someone using your product/project differently then you :-).   ;Quote:Original post by Mike2343@Thevenin: Umm... How does that answer the OPs question really?  You make us search google or the forums for "Fleurin" to get some obscure post about it (forth or fifth link down on google I think).Yah, I probably should have posted a screenshot of it or something. Anyways, I intended on showing him that not everyone in the field is using the latest OO design principles (Or any OO design principles at all, lol).Quote:Original post by Mike2343Btw hope you're projects going well, looked cool.Drawing my own art for it is going terrible, programming it is going terrific. ;  The problem with singletons is not just that they allow one instance, but alos they are a global (I believe). There is no reason to have a global renderer, or sound system, or scene manager, even if you truely only do need one of them. A far easier way is to create a regualr class and let the user know they only need to create one instance.The only real case I can think of where a singleton makes sense would be for the logging system. Generally, you will only need acces to one class (though it may be able to write to multiple files) and it will be needed to report status and errors from every subsystem of your application.   ;  Not all design patterns are good. Syntax-wise, the singleton DP is one of the simplest DP. When it comes to software design, it is probably one of the hardest to use. It is error prone and might lead to complex design problems - the kind of problem that makes you think "OMG! I have to redo everything!". Quote:Original post by Sr_GuapoThe problem with singletons is not just that they allow one instance, but alos they are a global (I believe). There is no reason to have a global renderer, or sound system, or scene manager, even if you truely only do need one of them. A far easier way is to create a regualr class and let the user know they only need to create one instance.Stricly speaking, singleton are not "global" - they encapsulate a unique global and give a centralized access to this global variable. This doesn't change the rightness of what you say. Quote:Original post by Sr_GuapoThe only real case I can think of where a singleton makes sense would be for the logging system. Generally, you will only need acces to one class (though it may be able to write to multiple files) and it will be needed to report status and errors from every subsystem of your application.Log systems don't have to be singletons. In fact, if you have only one log file then it's a far better idea to use functions - remember that in a C++ world not everythig is required to be an object. If you have more than one log file, I don't see the point of having a singleton interface.BTW, globals aren't inherently bad. In fact, I know at least one really useful C++ library that have at least 3 clever globals.@Thevenin: are you the sole developper of this project? How long will you maintain it? How many code lines is there in your project?I understand that not everyone follow the full set of OO design principles (I don't follow everything too; for example, I have some problems to correctly (and blindly) beleive that the Coad's rules (PDF, see slide 14 - the whole PDF is worth a reading) are really useful) - but explicitely doing the exact contrary is... weird.Quote:Scope Confusion: NONE! (via variable prefixing)That deserves a "Huh?!?!?" [smile]   