Need of privatizing assignment operator in a Singleton class

Question

Can someone justify the need of privatizing the assignment operator in a Singleton class implementation?

What problem does it solve by making Singleton& o

Answer 1

If you only want one instance, the copy constructor should be private. The assignment operator access specifier does not matter, because it will be impossible to use anyway.

Answer 2

My reasoning is this: if only one instance may be around, operator= could be defined without problem, since it will not do anything significant. if we make it private, the compiler will add one more level of safety by flagging any attempt to use that operator as an error.

The same reasoning holds for the destructor, by the way.

Answer 3

When you use a singleton the reason you implement it is because you only want one instance of an object of that class. In other words there is no need to make a copy of the instance because you can only have one instance. It is the same for the copy constructor.

Answer 4

Inherit boost::noncopyable (privately) in singleton class pattern than to define private copy construction and assignment operator.

Answer 5

Making the assignment operator private doesn't really change anything, since you need two instances to be able to assign. It does correspond to what people may expect to see; it's usual that if the copy constructor is private, the assignment operator is as well. Declaring a private assignment operator simply corresponds to people's expectations.

Answer 6

There's only one singleton. It makes no sense to copy it. You need two things for a copy to be sane and most copy operators need to check for self==&other in order to be safe.

This private trick is a hack. C++0x does it better.

Begin rant...

IMHO a Singleton is a contradiction in terms. It's a product of the silly idea that everything must be an object in order to be encapsulated. It's the same brainache that bore Java's Math.sin(x) et al.

Your life will be simpler if the "singleton" is simply a set of free functions in a namespace. Any private "members" of the singleton can be hidden in an anonymous namespace in the .cpp. Encapsulation achieved, and you don't have that cumbersome extra syntax.

MyNamespace :: foo ();

instead of

MyClass :: instance () .foo ();