Hola!

Hago esta pregunta desde la ignorancia, entiendo que virtual/override ayuda mucho a no tener que redefinir trozos de codigo de una función, sin embargo no entiendo cual es el fin de las funciones virtuales puras, es decir, no implementan nada, solo veo que ocupan un espacio en el archivo de cabecera, al fin y al cabo de todas formas tendrás que volver a declararlas y definirlas en las subclases como override...



Por qué no directamente?:

Gracias por responder.

Aunque de todas formas con el ejemplo que me das (que es valido) aun no le hallo sentido a tener que escribir una linea (funcion virtual pura) mas en la super clase ya que siempre en las subclases la tendré que declarar (override) y definir...  Veo a las funciones puras como una interfaz mas que nada, ejemplo:




No sería mejor esto?




De esta forma, de igual forma no necesito funcion virtual pura para hacer callar a la araña y para hacer cantar al canario...o no?

Yo diría que las funciones virtuales puras lo que hacen es imponer condiciones al programador. Imagina que creas una clase <Animal> que no vas a instanciar directamente sino que la vas a usar de molde para crear otras clases hijas que hereden de <Animal>. Entonces en esta clase <Animal> deberías crear funciones virtuales puras como <comer()>, <relacionarse()>, etc. Lo que consigues al hacerlas virtuales puras es que cuando crees un tipo de animal concreto y éste herede de <Animal> te verás "obligado" a redefinir esas funciones virtuales puras.

Puedes verlo también de otra forma. Tú puedes crear una clase abstracta de la que heredarán otras clases pero resulta que las clases hijas no las vas a hacer tú, sino que lo harán diferentes programadores, pero para que todo funcione bien tú necesitas decir al resto de programadores que sus clases deben contener una serie de funciones sí o sí. Cómo lo haces? Creas esas funciones como virtuales puras en la clase abstracta.
En el mismo ejemplo de antes, tú dices a un grupo de personas que se inventen unos animales y que tengan las características que ellos quieran PERO que todos los animales deben emitir un ruido, el que sea. Pues creas una función virtual pura que sea <emitirRuido()> y cuando las demás personas hagan que sus clases hereden de <Animal> deberán hacer que cada clase implemente de alguna forma esa función <emitirRuido()>.

Esto yo por ejemplo lo vi bastante bien al aprender Java donde esto se usa en las interfaces porque Java no permite la herencia múltiple. No lo he usado más que en un par de códigos pequeños en forma de "apuntes" pero digamos que así es cómo yo lo entiendo. Puede que tenga otros usos o interpretaciones y quien las conozca puede corregirme.

También:

Una función virtual pura convierte a la clase en una Clase Base Abstracta (una ABC - abstract base class), con la idea de separar la interfaz de la implementación.

Suponte que trabajas en una empresa que tiene toda una colección de clases a las que sus programadores deben obligatoriamente adscribir. Será una buena idea que se presenten como una "Interfaz" pura (una clase abstracta) y que si en algún momento se necesita modificar alguna parte de su implementación, ninguno de los quichicientos programas y progamitas que la usaron necesitarán ser recompilados.

Va un ejemplo de uso:

#include <iostream>
#include <string>
 
// Interfaz
class Empleado {
    //... todos lo que se pretende de un empleado abstracto
public:
    virtual std::string trabajar() = 0; // ya esto hace que la clase se abstracta.
    virtual void lamer_botas() {};
    virtual void ser_despedido() {};
    //...
};
 
// Un tipo de Empleado concreto:
//   - obligada a sobreescribir las funciones virtuales puras,
//   - se espera sobrescritas las otras virtuales
class Gerente : public Empleado {
    // ...
public:
    virtual std::string trabajar() override {
        return "Trabajen esclavos!\n";
    }
 
    // ...
};
 
void funcion_que_acepta_un_Empleado(Empleado& e) {
    std::cout << e.trabajar();
}
 
int main()
{
    //Empleado e; // Error: Empleado es una interfaz, no se puede crear un objeto de clase abstracta
 
    Gerente g; // Bien, este es un Empleado pero concreto.
 
    funcion_que_acepta_un_Empleado(g);  // esta funcion espera un Empleado como parametro.
}

Aquí la idea es que un Empleado es algo abstracto, una fantasía metafísica, inexistente en el mundo de las cosas. Pero se tienen funciones que trabajan con Empleados pasados por parámentro, de modo que se le puede pasar cualquier objeto que sea un Empleado concreto (de una clase derivada de Empleado). De este modo tienes código que actúa sobre Empleados, código genérico (durante la ejecución se decidirá de qué tipo de Empleado se trata).

Luego se podrá crear más tipos de Empleados, si hiciera falta, o modificar cualquiera de las funciones expuestas en la interfaz, y nadie sufrirá.

asi es...
salu2