2012-04-15 17 views
5

Sé por qué hacer que el constructor predeterminado y el constructor de copia sean privados para implementar la clase singleton en C++. Pero lo que no entiendo es por qué hacer que el operador de asignación de copias sea privado, porque para empezar no habrá dos objetos existentes.¿Por qué sobrecargar el operador de asignación de copia para una clase singleton en C++?

Mi exploración trae dos puntos:

  1. Según Alexandrescu en "Modern C++ Diseño", el operador de asignación a ser privados para evitar la auto-asignación.

  2. En segundo lugar, de acuerdo con rule of three, si se define una de Héctor, Héctor copia y operador de asignación para una clase, debe definir explícitamente los tres. Entonces, ¿es cuestión de seguir esta regla solamente?

Entonces, ¿cuál es su opinión sobre esto?

+0

¡No estoy cuestionando la explicación de Alexandrescu aquí! Quiero saber si hay una razón técnica o simplemente para informar al programador cliente que la asignación se previene. Porque si no declaramos op = entonces las construcciones de programadores como p1 = p2 pasarían silenciosamente. –

+0

Si usa un Singleton, entonces su diseño ya es tan malo, es ridículo que intente seguir la Regla de los Tres. – Puppy

+0

¿Realmente quieres permitir que compile? 'S :: getInstance() = S :: getInstance();' –

Respuesta

2

En un Singleton desea administrar toda la construcción es posible, misiones y destrucción. Al hacer todas esas operaciones private, en realidad solo evita que otros las usen.

También tenga en cuenta que normalmente la construcción de copia y la asignación de copias se declararán private para evitar la invocación desde el exterior pero no se definirán porque no se utilizan en la práctica ... y si el enlazador se quejaría.

En C++ 11 declararía la construcción de copias y la asignación de copias como delete d.

+1

Si entiendo el OP correctamente, no se puede usar la asignación de copia si los constructores son privados, ya que nadie será capaz de construir un lhs válido (excepto para uno mismo - caso de asignación). – Vlad

+0

@ Matthieu: ¿Es necesario declarar op = o es un problema de estilo aquí? –

+0

@RajendraUppal: no es solo un problema de estilo. Las operaciones sin sentido deberían estar prohibidas para que el mensaje sea claro: se advierte al usuario que hizo algo sin sentido y que puede reaccionar de manera adecuada. –

4

Creo que la necesidad de prohibir la asignación es más en consideraciones semánticas: como singleton es único, la asignación no tiene ningún sentido. Entonces, si sería técnicamente posible implementar la asignación de una manera razonable, lógicamente debe prohibirla de todos modos.

Entonces, exactamente porque nunca debe haber una necesidad de copiar un singleton, la operación debe estar prohibida. De lo contrario, hay lugar para la confusión y los errores: los desarrolladores harán intenten usarlo si está permitido (y se preguntan qué sucede).

El buen diseño minimiza la cantidad de WTF.

+0

Pero, decidamos no proporcionarlo, incluso si el programador cliente está haciendo algo como p1 = p2, (ambos se reciben de la llamada a GetInstance()) la auto asignación se ejecutará silenciosamente y no hay daño ya que ambos se están refiriendo a la misma instancia. –

+1

@Rajendra: bueno, se preguntarán por qué su código no funciona, lo cual es malo. Aunque técnicamente es quizás posible. El buen diseño no se trata solo de la corrección técnica, se trata de ayudar a las personas a ver lo que está sucediendo. – Vlad

+0

Entonces, ¿están conscientes antes de que puedan incluso compilar y ejecutar y preguntarse? –

Cuestiones relacionadas