Author Topic: Single instance of a class (Read 5633 times)

Astrof · « **on:** February 08, 2009, 05:33:36 am »

Ok, this is more of a general C++ question. I'm trying to use a ResourceManager class to manage resources. However I want to keep only one instance per program (as it stores all the resources for all of the program) or atleast I want its data to not change per instance if I make multiple instances.

So basically, is there a way I can make a static reference to one instance and just pass that around?

I'm just wondering how I would use a class to manage resources. I did this in Java programming by just making the constructor private and having one static reference, but I understand C++ is different (and that I could just use namespaces).

Anyway, I figured since the tutorial referenced a Manager class that people would have used it here.

stevend · « **Reply #1 on:** February 08, 2009, 03:26:44 pm »

look up the singleton pattern for c++ on google

spackle · « **Reply #2 on:** February 10, 2009, 04:52:07 am »

Then after you look up singleton, forget you looked it up. If you only want one instance of a class then only create one instance. Its just that easy. See http://scientificninja.com/advice/performant-singletons for more information.

Astrof · « **Reply #3 on:** February 10, 2009, 05:35:02 am »

oops, just made a singleton thing....
i'll give that article a read though, thanks!

quasius · « **Reply #4 on:** February 10, 2009, 06:40:50 am »

Quote from: "spackle"

Then after you look up singleton, forget you looked it up. If you only want one instance of a class then only create one instance. Its just that easy. See http://scientificninja.com/advice/performant-singletons for more information.

There are good reasons to use singletons. Such as learning to write code before learning about design perfection.

Nexus · « **Reply #5 on:** February 11, 2009, 03:01:43 pm »

Singletons really prevent one of creating multiple instances while "creating only one instance, it's that easy" implies no security at all. It's not always as easy as it seems, especially if the project's complexity grows. The situation is similar to "const" - beginners think of it "why declaring this const? I know I won't change the variable..."

C++ has a lot of mechanisms to make code as most foolproof as possible. Fundamentally, even the private/public separation tends to that direction...

quasius · « **Reply #6 on:** February 11, 2009, 05:47:21 pm »

One thing to keep in mind though is that a singleton is a "quasi-global" and, as you've probably heard, globals should be avoided. The reason is it becomes tempting and easy to access it from anywhere instead of maintaining reasonable dependencies.
Or put another way, think before you type "#include "MySingleton.h" if you should really be binding those 2 modules together or if there's a way to do what you need without creating that dependency.
(A situation where everything is dependent on everything is pejoratively called "spaghetti code.") But I think a lot of people who think singletons inherently cause spaghetti code have never seen truly hideously intertwined code. Such as years-old government projects that have been tossed from company to company with each one not giving a rat's ass about the code's maintainability after they fix their stuff and get it out the door...

Nexus · « **Reply #7 on:** February 11, 2009, 05:54:46 pm »

The problem is, that a lot of people abuse the singleton pattern as you stated, quasius. The original idea behind it was to prevent multiple instancing and not to become a better substitute for global variables.

There may be some cases where the quasi-global use is appropriate, but I think, in general, singletons are too often misunderstood. Not every manager class needs to be a singleton. Often, the pass by function parameters is safer and requires fewer dependencies. Debugging is easier when you know where an object can be changed. Globals imply the possibility to manipulate from everywhere.