Uso de los parámetros de tipo de subclase en funciones virtuales

Question

que tienen esta pieza de código (ideado a partir de mis problemas de la vida real)

no puede compilar, quejándose ExtendsB no implementa B::Run(A* a). Sin embargo, no tiene problemas para comprender la extensión de A* Run();

class A { }; 

class ExtendsA : public A { }; 

class B 
{ 
public: 
    virtual ~B(){} 
    virtual void Run(A* a) = 0; 
    virtual A* Run() = 0; 
}; 

class ExtendsB : public B 
{ 
public: 
    virtual ~ExtendsB(){} 

    // Not OK! It does not see it as an implementation of 
    // virtual void Run(A* a) = 0; 
    virtual void Run(ExtendsA* ea) {}; 
    virtual ExtendsA* Run() { return new ExtendsA(); }; // OK 
}; 

Por qué C++ permite cambiar el tipo de retorno a una sub-clase, pero no el tipo de parámetro?

¿Es una buena razón o solo un punto perdido en las especificaciones del idioma?

Answer 1

Por qué C++ permite cambiar el tipo de retorno a una subclase , pero no el tipo de parámetro?

C++ estándar permite el uso de un Covariant return type mientras overidding funciones virtuales, pero no permite modificar la función parameters.And sí hay una buena razón detrás de ella.

Justificación:

Anulación esencialmente significa que o bien el método de la clase Base o el método de clase derivada serán llamados en tiempo de ejecución dependiendo del objeto real señalado por el puntero.
implica que:
es decir: "Cada instancia donde se puede invocar el método de clase Base puede reemplazarse por una llamada al método de clase derivada sin ningún cambio en el código de llamada."

Si la regla anterior no estaba en su lugar, dejaría una ventana para romper el código existente mediante la adición de nuevas funcionalidades (nuevas clases derivadas).

Si tiene un prototipo de función en la clase derivada que difiere de los parámetros w.r.t de la función virtual de la clase base, la función no anula la función de la clase base, ya que la regla anterior se rompe.

Sin embargo, los tipos de retorno covariantes no rompen esta regla, porque upcasting sucede de forma implícita y un puntero de clase base siempre puede apuntar a un objeto de clase derivada sin ningún tipo de fundición, por lo tanto, la norma impone esta condición de tipos de retorno covariantes sobre los tipos de retorno.

Answer 2

El error es bastante claro: necesita void Run(A*) en su clase ExtendedB, pero no tiene eso. Todo lo que tiene es void Run(ExtendedA*), pero eso no es lo mismo: la clase base promete aceptar cualquierA -pointer, pero su ExtendedB::Run es más selectivo y solo acepta un subconjunto estrecho.

(Estás confundiendo covarianza y contravarianza, pero eso no es relevante para C++, ya que C++ no permite anulaciones contravariant.)

Answer 3

Es simplemente dos tipos diferentes, lo que lo convierte en dos funciones distintas con dos firmas distintas.

En general, si está utilizando un compilador que comprende C++ 11, debe usar la palabra clave override en las funciones que pretenden anular otra función. En su caso, el error se hizo aparente debido a la clase base abstracta, pero en otros casos tal error puede causar una gran depuración ...

Answer 4

La especialización del tipo de retorno hace que la subclase sea más estricta - actuará como un A. Sin embargo, restringir el método Run para aceptar solo una subclase del argumento original hace que B no actúe como A.

Modelos de herencia y una relación is-a. Tu código viola el principio de sustitución Liskov.