2010-08-17 19 views
14

Creo que lo virtual solo es generalmente suficiente.¿Debería un destructor de clase abstracta ser puro virtual?

¿Hay alguna otra razón para hacerlo puramente virtual que obligar a las clases derivadas a implementar su propio destructor? Quiero decir, si asigna algo al constructor de su clase, debe imponer su propio destructor, si su clase es derivada o no.

No cuenta como respuesta ya lo sé: si quieres que tu clase sea abstracta y no tenga funciones virtuales puras, déjala al destructor.

Algunos más usos?

+4

Tenga en cuenta que el compilador genera automáticamente un destructor en la clase derivada si no se proporciona explícitamente. Este destructor generado automáticamente es suficiente, no está obligado a escribir un destructor usted mismo, incluso si el de la clase base es puro. – sth

+0

Entonces, incluso el primer motivo es en realidad ninguno. Gran comentario! –

+0

Sólo una nota al margen: otra función que debe ser virtual es (cuando existe) el operador =. La misma razón que el dtor. – rkellerm

Respuesta

10

Si usted quiere que su clase abstracta y no tiene funciones virtuales puras - dejar que el destructor.

En realidad, no creo que haya más. Todo lo que hace el destructor virtual puro es hacer que toda la clase sea abstracta. Debe proporcionar la implementación para el destructor virtual puro, así como para un destructor virtual no puro, los destructores de las clases derivadas son virtuales con el destructor virtual solo, etc.

Básicamente, si una clase ya tiene algunas pure funciones virtuales, su comportamiento sería equivalente al destructor virtual y puro-virtual.

+0

+1 para la única respuesta correcta hasta el momento. –

+0

De hecho, es la respuesta, que coincide mejor con mi pregunta. –

11

No. Si la clase base asigna algo, es su responsabilidad liberarlo.

Además, si la clase derivada no distribuye nada, no tiene sentido obligarlos a escribir un dummy dtor.

+2

No los obligue a nada. Si no definen el destructor, el compilador lo hará por ellos. –

+0

@Tadeusz: ¿Incluso si es un virtual puro en la base? –

+1

Sí - probado con gcc 3.4.5. Pregunta: ¿Es ese estándar de C++ conformismo? –

-2

Si su clase abstracta es una interfaz pura, sin miembros de datos que usted podría llevarse bien con hacer el dtor puramente virtual. Yo mismo prefiero, ya que he visto tantos programadores de disparos en caliente olvidar hacer un destructor virtual en absoluto: incluso cuando escriben clases derivadas que contienen métodos virtuales. Así que lo haría simplemente para minimizar dolores de cabeza de mantenimiento en el camino.

+2

Olvidarse de escribir destructores es un riesgo en cualquier clase, ¡no solo en las clases derivadas! El mayor problema aquí es olvidar escribir un destructor virtual en la clase * base * –

+0

No estoy seguro de por qué hubo un voto negativo? ya que no hubo comentarios sobre por qué. Así que eso no es muy útil, si me falta algo, o Si no me articulé muy bien (lo que veo que podría haber usado un corrector de pruebas esta mañana). –

1

Idealmente, el lenguaje debe tener una manera de asegurar (implícita o no) que el destructor es virtual en clases abstractas sin tener que definirlo o hacerlo puro. Pero no es así.

Así que la elección es: o bien purificarlo, y tener la carga de definirlo en cada clase derivada, o no hacerlo, y tener la carga de definirlo en la clase abstracta. Lo último es menos trabajo, y también código más corto, así que iría por ello.

+0

Código más corto porque el dtor virtual puro tiene que implementarse fuera de la clase. El primer argumento contra el virtual puro! Gracias –

+1

En realidad, no creo que el código sea más corto. Compare '~ Klass() = 0' + su implementación y' ~ Klass() {} '. – jpalecek

+1

" + su implementación "es el punto, ya que no puede estar en línea, es decir, Klass :: ~ Klass() {} –

Cuestiones relacionadas