Need of privatizing assignment operator in a Singl

Question

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

What problem does it solve by making Singleton& operator=(Singleton const&); private?

class Singleton {
public:
  static Singleton& Instance() {
    static Singleton theSingleton;
    return theSingleton;
  }

private:
  Singleton(); // ctor hidden
  Singleton(Singleton const&); // copy ctor hidden
  Singleton& operator=(Singleton const&); // assign op. hidden
  ~Singleton(); // dtor hidden
};

Answer 1

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 2

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 ();

Answer 3

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 4

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

Answer 5

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 6

Assignment on a singleton is simply a nonsense operation since only one object of it should ever exist.

Making the assignment operator private helps diagnose nonsense code such as the following:

Singleton& a = Singleton::Instance();
Singleton& b = Singleton::Instance();
a = b; // Oops, accidental assignment.