Re: C++ Singleton problem...
tobias.sturn wrote:
Now i have a class which uses these macros but now i still i can write
constructors make them public and i have won nothing...
class Class
{
public:
Class(int a) {/*i have created an object :(*/
Class(char a)...
};;
You can't. The point of classes is to be upgraded and re-used. Deal.
How could i make it not possible for the user of the template that he
cant override the constructor?
The mininimal situation worked for me:
class frob {
DECLARE_SINGLETON(frob);
};
DEFINE_SINGLETON(frob);
frob::frob() {}
#include <assert.h>
#include <stdlib.h>
int main()
{
frob * pFrob = frob::getInstance();
assert(NULL != pFrob);
// frob aFrob; // <-- bad
return 0;
}
Now about your style. "Singleton" is the most abused pattern in /Design
Patterns/, and it's the best candidate for time travel to tell the GOF to
take it out. I can think of many situations where a program needs only one
of something, but I can't think of any situation where a program should
never have more than one of something.
Next, you should use unit tests (like my main()), and should pass them after
every edit. This implies that some of your classes should use a mock object
instead of your singleton. So that implies that tests have legitimate
reasons to re-use more than one instance of your singleton, to construct
them with extra data, and to derive from them.
Next, a Singleton is not an excuse for a global variable. Most clients of
your singleton should pass it in by reference. They should not rely on it
floating around in space. So nearly all clients of your singleton should
accept a reference that your tests can mock.
Next, you are abusing macros. You should instead abuse templates. Google for
[c++ singleton template], and get sample code like this:
http://www.codeproject.com/cpp/singleton_template.asp
Next, neither your getInstance() nor the one on that page can return a NULL
pointer, so they should return a reference to the Singleton. Whichever
pattern you go with, make that small fix.
Next, I suspect this is the best implementation for the getter:
static T& Instance()
{
static T aT;
return aT;
};
That is well-defined to construct aT at least before the first time the
function enters, so it fixes the common C++ problem with global variables
constructing out of order, and fixes it without the odious choice of a 'new'
call. Other patterns and situations may easily apply here, too.
After applying any subset of my suggestions, you will have a better program
with less need to restrict your constructors.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!