I talked Singleton with my friends yesterday:2 java programmers, 1 C++ programmer. We have three implementations.
I think this is dependent on Java language, when the class is loading, static instance will be initialized only once.
I think this implementation can work in any language.
It can work correctly in C++! But it's not the case in Java. Even we can replace Line 1 with "static Singleton instance = new Singleton();". It can still work in C++. I think it's must be the difference between static in Java and C++.
Do you think so? Then Why Java and C++ treat static in a different way? Which one is better?
#1 is my personal favorite. #2 is fine if you synchronize the getInstance method to be thread safe. #3 you found does not work in Java. I don't know C++ enough to say much more than I'm surprised it works.
We never let a Singleton question go by without suggesting a careful review to make doubly sure it's the right solution. Singleton is overused and carries along a lot of limitations.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
A class member defined in this way (i.e. static Date default_date) only has its memory allocated - and it is allocated in �static memory� (i.e. it doesn't come off the heap - in Java all objects are allocated from the heap). To initialize the object you need to additional action in the implementation file:
The static member is initialized by telling the Date constructor to initialize the memory of Date::default_date. Also note that
isn't a typo. There is no new. Essentially this runs the constructor straight over the existing memory of default_date. The standard syntax
does two things:
Allocates memory for the object from the heap.
Initializes the memory to an object by running the constructor(s) over it.
So really the difference is that in C++ object memory can be allocated in "static memory", a stack frame, or from the heap (only objects allocated from the heap have to be de-allocated), while in Java all Objects are allocated from the heap. [ June 01, 2007: Message edited by: Peer Reynders ]
I'm sorry I haven't the C++ code when I post this paste. Now I get it.
We invoke getInstance for two times and print the address for the object. They are same. If I write like this in Java, it will be two objects. As Peer said, the resason is C++ allocate memory for static object in static memory, but Java allocate it in heap. So my friend's implementation is right, although it's not appeared in GOF's book.
Stan,thanks for you suggestion. I see there is overuse of Singleton. And often see "Create Once" in this forum. But now we are just earning them one by one. So I want to totaly understand of them.
Joined: Aug 19, 2005
Originally posted by Louis Wang: As Peer said, the resason is C++ allocate memory for static object in static memory, but Java allocate it in heap. So my friend's implementation is right, although it's not appeared in GOF's book.
Actually in the example you provided the Singleton object is allocated from the heap. new always allocates memory from the heap. What is in the program's static symbol table is the pointer _myInstance. This means that even though _myInstance looks like a local variable, it isn't actually on the method's stack frame. _myInstance persists outside of CSingleton::GetInstance but is only accessible inside CSingleton::GetInstance. That also means the line:
executes exactly once - the first time CSingleton::GetInstance runs � after that it never runs again.
So basically this Singleton uses some of the dustier C/C++ features which the Java designers deliberately did not duplicate as they tend to obfuscate the overall intent. Personally I prefer the GoF version as it is clear in what it is trying to accomplish but I guess that is somewhat subjective.
Java and C/C++ treat "static" differently in that C/C++ allows static local variables, which Java doesn't.
When I started working in Java, I actually missed static local variables quite a bit, but today I think in an OO language they are a code smell. I feel that they are an artefact of procedural thinking: they are basically a member variable that is only visible in one method, which means that the class is lacking cohesion.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus