Traditional Singleton Implementation vs Static Object Singleton Implementation

[koki]

I have usually implemented Singletons as described in the Design Patterns book. Recently someone suggested another implementation of Singleton using creating a static instance of a class and returning that instead of using new and returning a pointer to the new singleton. I would like to get your input. Is there any advantages of using one or the other? Disadvantages? Disadvantages for the static singleton implementation?

Let me illustrate:

Traditional Singleton Implementation

Car* Car::getInstance()
{
if(!InstanceFlag)
{
Instance = new Car();
InstanceFlag = true;
return Instance;
}
else
{
return mp_Instance;
}
}

Static Implementation

Car& Car::getInstance()
{
static Car theCar;
return theCar;
}

Advantages & Disadvantages? Any documents or articles I can refer to for the second implementation ? Thanks for your help!

[bartoli]

There must be something missing in this code. The getInstance methods must be static. Otherwise, you can't call getInstance() if you don't have a Car object already, so the method would be useless.
And if you had the method static, the variables InstanceFlag and mp_INstance would have to be static too, so the first one would only be a more complicated version of the second one.
Also, if getInstance() doesn't assign the address of the car to mp_Instance, it woun't be able to return it on later calls (unless it is set in the constructor maybe)

[hanst99]

using creating a static instance of a class and returning that instead of using new and returning a pointer to the new singleton

You can do it differently than that? I only know the single being like this:

class Singleton
{
private:
Singleton();
~Singleton();
static Singleton* instance;
public:
static Singleton* getInstance();
};

[koki]

bartoli, there may be implementation details left out but the main question is what is the advantage of #1 vs #2 and viceversa. I have used #1 mostly as it is stated in the Design Patterns book and well know in the industry. #2 allows you to allocate the memory a compile time and avoid trashing the heap (problems identified earlier). Also no dynamic memory allocation necessary. I have already used #2 and works fine. Give it a try and let me know!

hanst99, what you stated is what I have used in the past until I saw #2. I wonder why there is no documentation about it or is on some design patterns book.

Any more thoughts? Anyone else has any input? Thanks for your help!

[bartoli]

Those implementation details i mention were meant to show that #1 can't work without using static, so #1 and #2 are using the same method

Or maybe you mean for #1 something like :

A* Aptr = NULL;//global, since making it static in the function would be the same as #2
A* getA(){
 if(Aptr) return Aptr;
 else return (Aptr=new A());
}

In that case, the difference would be that with #2, you are sure that A will never be built more than once. The code itself forbids it
With #1, you can't guarantee that an other programmer (or you in 6months) won't just build an other A

[Galik]

Some reading about the problems with statics:

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.15

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.16