Por lo que entiendo, la introducción de override
palabras clave en C ++ 11 no es más que una verificación para asegurarse de que la función que se implementa es la función override
de una virtual
función en la clase base.
¿Es asi?
Por lo que entiendo, la introducción de override
palabras clave en C ++ 11 no es más que una verificación para asegurarse de que la función que se implementa es la función override
de una virtual
función en la clase base.
¿Es asi?
Respuestas:
Esa es de hecho la idea. El punto es que usted es explícito sobre lo que quiere decir, de modo que se pueda diagnosticar un error silencioso:
struct Base
{
virtual int foo() const;
};
struct Derived : Base
{
virtual int foo() // whoops!
{
// ...
}
};
El código anterior se compila, pero no es lo que debiste haber querido decir (ten en cuenta lo que falta const
). Si dijiste en su lugar, virtual int foo() override
obtendrías un error del compilador de que tu función no anula nada.
override
función "arregla" esto; debes recordar usarlo, tal como deberías haber recordado escribir el const
;)
explicit
las definiciones de clase no llegaron a C ++ 11. Huh
explicit
definición de clase? Nunca he oído hablar de eso en absoluto.
override
cuando uno tiene la intención de hacerlo) es más probable que recordar casos de esquina, es decir, no hay generalidad en copiar funciones de diferentes prototipos, solo irregularidades como faltar const
o escribir en char
lugar de int
, etc.
override
especificador se menciona en esta respuesta , que es más futurista que inmediato. La respuesta sugiere que, mantenga override
el virtual
método. En el futuro, cuando un error cambia la firma, sus patadas utilidad en.
Cita de Wikipedia:
El identificador especial de anulación significa que el compilador verificará la (s) clase (s) base (s) para ver si hay una función virtual con esta firma exacta. Y si no lo hay, el compilador generará un error.
http://en.wikipedia.org/wiki/C%2B%2B11#Explicit_overrides_and_final
Editar (intentando mejorar un poco la respuesta):
Declarar un método como "anulación" significa que ese método está destinado a reescribir un método (virtual) en la clase base. El método de anulación debe tener la misma firma (al menos para los parámetros de entrada) que el método que pretende reescribir.
¿Por qué es esto necesario? Bueno, se evitan los siguientes dos casos de error comunes:
uno escribe mal un tipo en el nuevo método. El compilador, sin saber que tiene la intención de escribir un método anterior, simplemente lo agrega a la clase como un nuevo método. El problema es que el método anterior todavía está allí, el nuevo se agrega solo como una sobrecarga. En este caso, todas las llamadas al método anterior funcionarán igual que antes, sin ningún cambio en el comportamiento (que habría sido el propósito de la reescritura).
uno olvida declarar el método en la superclase como "virtual", pero aún intenta reescribirlo en una subclase. Si bien esto aparentemente será aceptado, el comportamiento no será exactamente como se esperaba: el método no es virtual, por lo que el acceso a través de punteros hacia la superclase terminará llamando al método antiguo (superclase ') en lugar del método nuevo (subclase').
Agregar "anulación" claramente desambigua esto: a través de esto, uno le está diciendo al compilador que tres cosas están esperando:
Si alguno de estos es falso, entonces se señala un error.
* nota: el parámetro de salida es a veces de tipo diferente, pero relacionado. Lea sobre las transformaciones covariantes y contravariantes si está interesado.
La " anulación " encontrada es útil cuando alguien actualizó la firma del método virtual de la clase base, como agregar un parámetro opcional, pero olvidó actualizar la firma del método de la clase derivada. En ese caso, los métodos entre la base y la clase derivada ya no son una relación polimórfica. Sin la declaración de anulación, es difícil descubrir este tipo de error.
override
es una excelente manera de descubrir tales problemas, una buena cobertura de pruebas unitarias también debería ayudar.
Si, esto es asi. Es una verificación para asegurarse de que uno no intente anular y estropearlo con una firma fallida. Aquí hay una página Wiki que explica esto en detalle y tiene un breve ejemplo ilustrativo:
http://en.wikipedia.org/wiki/C%2B%2B11#Explicit_overrides_and_final
C ++ 17 borrador estándar
Después de repasar todos los override
éxitos en el borrador estándar C ++ 17 N4659 , la única referencia que puedo encontrar al override
identificador es:
5 Si una función virtual está marcada con la anulación virt-specifier y no anula una función miembro de una clase base, el programa está mal formado. [Ejemplo:
struct B { virtual void f(int); }; struct D : B { virtual void f(long) override; // error: wrong signature overriding B::f virtual void f(int) override; // OK }
- ejemplo final]
así que creo que posiblemente explotar programas incorrectos es en realidad el único efecto.