 |
|
 |
What about this:
static T& Instance()
{
static T instance;
return instance;
}
I've never seen this solution, but maybe this is somehow considered bad form.
thoughts?
|
|
|
|
 |
|
 |
This singleton template is flawed because it does not stop a coder from deriving from the template class and also creating a separate instance. In other words, it does not stop the user of the template from creating a derived class with a public constructor, thus negating the whole point of the singleton.
I make this statement not from malice, but from the position of raising the question: How do you stop someone from deriving a class from your singleton template and having a public constructor and thus a whole series of separate objects?
|
|
|
|
 |
|
 |
I've found the article very useful, and I just wanted to integrate it in a project.
I have to templatize CMySigleton class, and then subclass it adding more functionality in CMySingletonExt class. Finally I want to specialize the CMySingletonExt class, but I'm having troubles compiling. I think I understand where the problem comes from, but I'm stuck trying to overcome it.
Specifically, I'm doing the following:
template <class T>
class CMySingleton : public CSingleton<CMySingleton<T>>
{
friend CSingleton<cmysingleton>;
private:
CMySingleton();
~CMySingleton();
protected:
T m_oData;
};
template <class T>
class CMySingletonExt : public CMySingleton<T>
{
public:
void NewOperationToProcessData()
{
}
};
class CMyClass : public CMySingletonExt<int>
{
public:
};
int _tmain(int argc, _TCHAR* argv[])
{
CMyClass::Instance()->NewOperationToProcessData();
return 0;
}
</cmysingleton>
But the compiler complains with the following message:
error C2039: 'NewOperationToProcessData' : is not a member of 'CMySingleton<t>'</t>
Is there someone that could help me?
Thanks in advance.
PS.: If there is other place to post this please, let me know, and sorry for the possible inconveniences.
|
|
|
|
 |
|
 |
I couldt make it compile was getting this error.
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:\sandbox\tmepret\tmepret\tmepret.cpp(60) : see reference to class template instantiation 'CSingleton' being compiled
so i added a void statement in the DestroyInstance() function.
static void DestroyInstance()
{
delete m_instance;
m_instance = NULL;
};
and it compiled without a complaint.
|
|
|
|
 |
|
 |
this code does implement the template singleton
|
|
|
|
 |
|
 |
Hey there,
http://www.codeproject.com/cpp/pdesingletontemplatenomfc.asp
is my take on the subject, may help you out if this didn't switch on any light-bulbs!
Cheers,
Paul
/**********************************
Paul Evans, Dorset, UK.
Personal Homepage "EnjoySoftware" @
http://www.enjoysoftware.co.uk/
**********************************/
|
|
|
|
 |
|
 |
A true Singleton KNOWS how to destroy itself!
In your sample, the person has to do this him/herself. See page 133 of Alexandrescu book (for one way) on how the Singleton can destroy itself.
I say, "one way," because Alexandrescu himself, does not tell everything. My feeling is that he knows more than he lets out. Even from attending a seminar in which he was a featured speaker, he dosen't tell all. Whether this might be because he's working on other techniques, he only give clues.
Chapter 6 of his book (on just Singletons), give the reader quite a bit to digest.
William
Fortes in fide et opere!
|
|
|
|
 |
|
 |
WREY wrote:
A true Singleton KNOWS how to destroy itself!
I agree that would be a nice feature, but it is not mandatory. As I stated before this article was based on an idea that seemed to be flawed. Hence, I'm thinking of deleting the article.
|
|
|
|
 |
|
 |
I don't know if you mean the idea of a Singleton is flawed, or the idea of it destroying itself, is flawed.
Personally, I don't believe neither is, because there are times when you need to work with an object that you want to know for sure, ONLY ONE EXISTS!! The Singleton fills that requirement.
The other thing you need to know, is that the Singleton has the capacity to destroy itself; thereby relieving you of all responsibilities of worrying when you ought to destroy it.
Those two requirements are not just nice features to have, they are something you expect the Singleton to provide, and Alexandrescu goes to extra length of certifying in all his examples that none of these qualities are missing.
For the beginner, getting to learn about this pattern seems easy and almost trivial at the start, but as you become more aware of its uniqueness and power, you begin to realize how really difficult it is to use at times, particularly in a multithreaded environment when your reliance is counting on the fact that some other thread cannot create another Singleton.
The opposite side to that concern, is that you don't want to have to worry either about destroying the Singleton object too early while another thread might be using it. This is where Alexandrescu insist that a genuine Singleton, must know when to destroy itself, using the mechanism of the language itself (and to that end, he gave an example of how this can be accomplished in his book, of which I have already quoted).
To say it is a nice feature, but not mandatory, is just as good as saying you don't need a way of controlling multiple threads from colliding with each other and doing damage.
William
Fortes in fide et opere!
|
|
|
|
 |
|
 |
As pointed out by Jörgen Sigvardsson, the Singleton implementation was not bulletproof. So I updated the code and article somewhat. I made the copy constructor private, so no copies can be made of the tempate and derived class. I also cwhanged the implementation of the derived class. You must make the constructor and destructor of the derived classes private. This way no instance can be made of the derived class. So, in order to let the singleton class make an instance of the derived class, you must make it a friend.
I guess now you have to add more code to your base class in order to make it a singleton, the singleton base class adds less value. But well, it was a nice exercise .
|
|
|
|
 |
|
 |
This class doesn't really live up to the full singleton pattern. There are still ways to ignore the singleton rules - you can still create instances of your singleton class by not using the template.
--
Shine, enlighten me - shine
Shine, awaken me - shine
Shine for all your suffering - shine
|
|
|
|
 |
|
 |
Jörgen Sigvardsson wrote:
This class doesn't really live up to the full singleton pattern. There are still ways to ignore the singleton rules - you can still create instances of your singleton class by not using the template.
Could you elaborate? I don't see that, and I'm considering using this (already have, but I'm not committed)
Thx
|
|
|
|
 |
|
 |
At first the singleton implementation class did not hide its constructor nor destructor. This means that you could create instances of it without having to go through Instance of the singleton utility template.
The author has changed his article now, and at a glance, it looks like he's managed to correct this. He made the constructor and destructor of the singleton implementation class private and the singleton utility template a friend.
--
Shine, enlighten me - shine
Shine, awaken me - shine
Shine for all your suffering - shine
|
|
|
|
 |
|
 |
I'm afraid your right, I did some more testing and I turns out that it is possible to create and instance of a derived class. The only way to work around this problem is by making the constructor of the template and derived class private and make the template class a friend of the derived class. Damn, I have to thing this over again (and rewrite the article I guess).
|
|
|
|
 |
|
 |
CreateSingleton:{
if (object == NULL) object = new object
return object
}
If this is a "good" singleton pattern, why NOT just create a static or global variable/object? Simple!
Singleton is not "very" critica; but to create a "good" Singleton object must do more than your method. Why other people use private constructor? I guess you know since you did your homework already. I would think again?
|
|
|
|
 |
|
 |
Anonymous wrote:
If this is a "good" singleton pattern, why NOT just create a static or global variable/object? Simple!
The object I create is a static member variable. And global variables are just plain damn ugly.
|
|
|
|
 |
|
 |
Ok, finally you use private constructor.... This is the key. However, to create a singleton object is not so hard but is not so easy; . It really deponds how app use "singleton object". Bruce Eckel wrote some singleton object (pattern) in his
Think in xxx, (C++, Java, Pattern...)
If you are interested, they are good articles.
|
|
|
|
 |
|
|
 |
|
 |
Barry Lapthorn wrote:
Alexandrescu's book
It is eye popping. Takes a really long time to read one chapter. But good, very good!
|
|
|
|
 |
|
 |
Very few C++ programmers admit that they like templates because many frowns at the very idea of templates. It's like pornography, and Alexandrescu is the Hugh Hefner of C++ programming.
--
Shine, enlighten me - shine
Shine, awaken me - shine
Shine for all your suffering - shine
|
|
|
|
 |
|
 |
This is without doubt one of THE most amazing books I've ever read. It takes ages to understand - but the implications of what he does are incredible.
Templates for
- Singletons
- Factories
- Threads
- Dispatch engines
Talk about abusing your compiler - this does it all!
And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter
"I ask candidates to create an object model of a chicken." -Bruce Eckel
|
|
|
|
 |
|
 |
I never wrote a lot of template classes because ATL and STL already provide a lot of useful and powerful template classes. But it really is a powerful mechanism. I will take a look at it.
|
|
|
|
 |