Hi guys,
I was wondering if (in C++) you can instantiate a class (class foo) then have said class return the already instantiated object. (foo::instance())
In other words, can I have a class return it's-self via it's own methods? I want to be able to create a class (i.e. class foo) early in my program so it is already setup and ready to go. Then, farther down the line, I want to be able to call functions from that class without having to pass that object as an argument to my calling function. Can I do something like so: MyClass::ReturnSelf()->foo();
or MyClass::ReturnSelf().foo();
I want to be able to create a class (i.e. class foo) early in my program so it is already setup and ready to go.
foo anInstance;
Then, farther down the line, I want to be able to call functions from that class without having to pass that object as an argument to my calling function.
anInstance.someClassFunction();
Is this not just how a class is normally used? Have I misunderstood your question?
The singleton pattern, basically has a private member variable of the same type as the class and also hides its constructor(s) and destructor from the outside, so these too go in the private section of the class (or protected if you need to inherit from this class). Finally, you implement a public static method to get the single instance of this class.
@mik2718 @ajh32: Are you serious ? It's obvious he isn't talking about a singleton.
A singleton has nothing to do with creating/returning an instance of the class. It guarantees that the instance will be unique. That's a totally different problem.
@snow 56767: As Moschops said, what you describe is just how a class is normally used in C++;
1 2
MyClass MyObject(/* optional arguments here */); // create an instance of MyClass
MyObject.foo();
Well, I can get my code to compile now. But, my instance returning method returns a new instance every time it is called and I don't want that. I need there to be one and ONLY one instance of the class during the lifetime of the application and I need to be able to return said instance. And the reason I can't just say, declare class Foo as global then use it that way the class is used through-out the code. It is also a bad practice to have global variables unless necessary and the new and delete operators are too slow for what I'm doing. So what I need is a class that returns a single initialized instance of it's-self via a static method. That way the members are persistent between calls and the class is only ever initialized once. I believe this means I need a Singleton class, but I'm not sure.
While I don't feel that I know enough about design patterns to make a recommendation here, I can contribute a link to where many patterns are classified and presented:
http://sourcemaking.com/design_patterns
In the monostate pattern all the data is static but the methods are not, when you make a new instance of the class you actually get a new instance, but it is gauranteed to be the same as all the other instances because of the all-static data
// in header
class MyMonostate
{
private:
static mycomplexdata* data;
staticbool initialised;
void initialise();
public:
MyMonostate(); // get an "instance"
...
// other methods
...
};
// in cpp file
// define initial static data values
mycomplexdata* MyMonostate::data = NULL;
bool MyMonostate::initialised = false;
void initialise()
{
// set up complex data here
...
// at end of this function
initialised = true;
}
// constructor, calls initialise the first time only
MyMonostate::MyMonostate()
{
if(initialised)
return;
initialise();
}
Whenever you want to use the class you just create one, and start using it. The first time you do this the initialise() method will be called, it will not be called again.
both monostate and singleton can have problems when multithreading is used
Thanks for posting the Monostate pattern. I haven't seen that before, but on first glance it looks vastly preferable to singletons. Traditional singletons are, frankly, vile, especially if you're working in a Test-Driven Development environment. I understand that it's convenient to be able to pull an instance with a persistent state out of the ether at any point in your code, but it introduces so much coupling and other annoying complications that I would recommend against using them to pretty much anyone.
This monostate pattern looks like a much better alternative.