C++, una panoramica sul linguaggio

Funzioni virtuali

Il meccanismo dell'ereditarieta` e` stato gia` di per se una grande innovazione nel mondo della programmazione, tuttavia le sorprese non si esauriscono qui. Esiste un'altra caratteristica tipica dei linquaggi a oggetti (C++ incluso) che ha valso loro il soprannome di "Linguaggi degli attori", tale caratteristica consiste nella possibilita` di rimandare a tempo di esecuzione il linking di una o piu` funzioni membro (late-binding), ma andiamo con ordine.
L'ereditarieta` pone nuove regole circa la compatibilita` dei tipi, in particolare se Ptr e` un puntatore di tipo T, allora Ptr puo` puntare non solo a istanze di tipo T ma anche a istanze di classi derivate da T (sia tramite ereditarieta` semplice che multipla). Se Td e` una classe derivata (anche indirettamente) da T, istruzioni del tipo

  T * Ptr = 0;		 // Puntatore nullo
  /* ... */
  Ptr = new Td;

sono assolutamente lecite e il compilatore non segnala ne errori ne warning.
Cio` consente ad esempio la realizzazione di una lista per contenere tutta una serie di istanze di una gerarchia di classi, magari per poter eseguire un loop su di essa e inviare a tutti gli oggetti della lista uno stesso messaggio. Pensate ad esempio ad un programma di disegno che memorizza gli oggetti disegnati mantenendoli in una lista, ogni oggetto sa come disegnarsi e se e` necessario ridisegnare tutto il disegno basta scorrere la lista inviando ad ogni oggetto il messaggio di Paint.
Purtroppo la cosa cosi` com'e` non puo` funzionare poiche` le funzioni sono linkate staticamente a compile-time. Anche se tutte le classi della gerarchia possiedono un metodo Paint(), noi sappiamo solo che Ptr punta ad un oggetto di tipo T o T-derivato, non conoscendo l'esatto tipo una chiamata a Ptr->Paint() non puo` che essere risolta chiamando Ptr->T::Paint() (che non fara` cio` che vorremmo). Il compilatore non puo` infatti rischiare di chiamare il metodo di una classe derivata, poiche` questo potrebbe tentare di accedere a membri che non fanno parte dell'effettivo tipo dell'oggetto (causando inconsistenze o un crash del sistema), chiamando il metodo della classe T al piu` il programma non fara` la cosa giusta, ma non mettera` in pericolo la sicurezza e l'affidabilita` del sistema (perche` un oggetto derivato possiede tutti i membri della classe base).
Si potrebbe risolvere il problema inserendo in ogni classe della gerarchia un campo che stia ad indicare l'effettivo tipo dell'istanza:

    enum TypeId { T-Type, Td-Type };

    class T {
        public:
            TypeId Type;
            /* ... */

        private:
            /* ... */
    };

    class Td : public T {
        /* ... */
    };

e risolvere il problema con una istruzione switch:

    switch (Ptr->Type) {
        case T-Type :
            Ptr->T::Paint();
            break;
        case Td-Type :
            Ptr->Td::Paint();
        default :
            /* errore */
    };

Una soluzione di questo tipo funziona ma e` macchinosa, allunga il lavoro, una dimenticanza puo` costare cara e soprattutto ogni volta che si modifica la gerarchia di classi bisogna modificare anche il codice che la usa.
La soluzione migliore e` invece quella di far in modo che il corretto tipo dell'oggetto puntato sia automaticamente determinato al momento della chiamata della funzione e rinviando il linking di tale funzione a run-time.
Per fare cio` bisogna dichiarare la funzione membro virtual:

  class T {
    public:
      /* ... */
      virtual void Paint();

    private:
      /* ... */
  };

La definizione del metodo procede poi nel solito modo:

  void T::Paint() {	// non occorre mettere virtual
    /* ... */
  }

I metodi virtuali vengono ereditati allo stesso modo di quelli "normali" (o meglio statici), possono anch'essi essere sottoposti a overloading ed essere ridefiniti, non c'e` alcuna differenza eccetto che una loro invocazione non viene risolta se non a run-time. Quando una classe possiede un metodo virtuale, il compilatore associa alla classe (non all'istanza) una tabella che contiene per ogni metodo virtuale l'indirizzo alla corrispondente funzione, ogni istanza di quella classe conterra` poi al suo interno un puntatore alla tabella; una chiamata ad una funzione membro virtuale (e solo alle funzioni virtuali) viene risolta con del codice che accede alla tabella corrispondente al tipo dell'istanza tramite il puntatore contenuto nell'istanza stessa, ottenuta la tabella invocare il metodo corretto e` semplice.
Le funzioni virtuali hanno il grande vantaggio di consentire l'aggiunta di nuove classi alla gerarchia e di renderle immediatamente e correttamente utilizzabili dal vostro programma senza doverne modificare il codice, basta solo ricompilare il tutto, il late-binding fara` in modo che siano chiamate sempre le funzioni corrette senza che il vostro programma debba curarsi dell'effettivo tipo dell'istanza che sta manipolando.
L'invocazione di un metodo virtuale e` piu` costosa di quella per una funzione membro ordinaria, tuttavia il compilatore puo` evitare tale overhead risolvendo a compile-time tutte quelle situazioni in cui il tipo e` effettivamente noto; ad esempio:

    Td Obj1;
    T * Ptr = 0;
    /* ... */
    Obj1.Paint();   // Chiamata risolvibile staticamente
    Ptr->Paint();   // Questa invece no

La prima chiamata al metodo Paint() puo` essere risolta in fase di compilazione perche` il tipo di Obj1 e` sicuramente Td, nel secondo caso invece non possiamo saperlo (anche se un compilatore intelligente potrebbe cercare di restringere le possibilita` e, in caso di certezza assoluta, risolvere staticamente la chiamata). Se poi volete avere il massimo controllo, potete costringere il compilatore ad una "soluzione statica" utilizzando il risolutore di scope:

    Td Obj1;
    T * Ptr = 0;
    /* ... */
    Obj1.Td::Paint();   // Chiamata risolta staticamente
    Ptr->Td::Paint();   // ora anche questa.

Adesso sia nel primo che nel secondo caso, il metodo invocato e` Td::Paint(). Fate attenzione pero` ad utilizzare questa possibilita` con i puntatori (come nell'ultimo caso), se per caso il tipo corretto dell'istanza puntata non corrisponde, potreste avere delle brutte sorprese.
Il meccanismo delle funzioni virtuali e` alla base del polimorfismo: poiche` l'oggetto puntato da un puntatore puo` appartenere a tutta una gerarchia di tipi, possiamo considerare l'istanza puntata come un qualcosa che puo` assumere piu` forme (tipi) e comportarsi sempre nel modo migliore "recitando" di volta in volta il ruolo corretto (da qui il soprannome di "Linguaggi degli attori"), in realta` pero` un'istanza non puo` cambiare tipo, e solo il puntatore che puo` cambiare tipo e istanza.
Se decidete di utilizzare le funzioni virtuali dovete ricordare che quando derivate una nuova classe, se decidete di ridefinire un metodo virtuale di una classe base, esso dovra` essere dichiarato ancora virtual, altrimenti il meccanismo viene interrotto. Fate attenzione anche in casi di questo tipo:

  class T {
    public:
      virtual void Foo();
      virtual void Foo2();
      void DoSomething();

    private:
      /* ... */
  };

  /* implementazione di T::Foo() e T::Foo2() */

  void T::DoSomething() {
    /* ... */
    Foo();
    /* ... */
    Foo2();
    /* ... */
  }


  class Td : public T {
    public:
      virtual void Foo2();
      void DoSomething();

    private:
      /* ... */
  };

  /* implementazione di Td::Foo2() */

  void Td::DoSomething() {
    /* ... */
    Foo();     // attenzione chiama T::Foo()
    /* ... */
    Foo2();
    /* ... */
  }

Si tratta di una situazione pericolosa: la classe Td ridefinisce un metodo statico (ma poteva anche essere virtuale), ma non uno virtuale da questo richiamato. Di per se non si tratta di un errore, la classe derivata potrebbe non aver alcun motivo per ridefinire il metodo ereditato, tuttavia puo` essere difficile capire cosa esattamente faccia il metodo Td::DoSomething(), soprattutto in un caso simile:

  class Td2 : public Td {
    public:
      virtual void Foo();

    private:
      /* ... */
  };

Questa nuova classe ridefinisce un metodo virtuale, ma non quello che lo chiama, per cui in una situazione del tipo:

  Td2 * Ptr = new Td2;
  /* ... */
  Ptr->DoSomething();

viene chiamato il metodo Td::DoSomething() ereditato, ma in effetti questo poi chiama Td2::Foo() per via del linking dinamico. Consiglio vivamente di riflettere sull'evoluzione di una esecuzione di funzione che chiami funzioni virtuali, solo in questo modo si apprendono vantaggi e pericoli derivanti dall'uso di funzioni virtuali.
Per concludere l'argomento resta solo da dire che qualsiasi funzione membro di una classe puo` essere dichiarata virtual (anche un operatore, come vedremo), con l'eccezione dei costruttori. I costruttori infatti, in presenza di classi con funzioni virtuali, hanno il compito di inizializzare il puntatore alla tabella dei metodi virtuali contenuto nell'istanza e quindi non essendo ancora stabilito il link tra istanza e tabella non e` materialmente possibile avere costruttori virtuali. Si noti inoltre che non conoscendo il momento in cui tale link sara` stato stabilito, non e` lecito chiamare metodi virtuali all'interno dei costruttori (a meno che non si forzi il linking statico con il risolutore di scope). Ovviamente non esiste alcun motivo per cui un distruttore non possa essere virtuale, anzi in presenza di funzioni virtuali e` sempre bene che anche il distruttore lo sia (al 99,9% e` necessario, negli altri casi e` una garanzia per il funzionamento del programma, soprattutto in previsione di future revisioni).

Classi astratte

I meccanismi dell'ereditarieta` e delle funzioni virtuali possono essere combinati per realizzare delle classi il cui unico scopo e` quello di stabilire una interfaccia comune a tutta una gerarchia di classi:

  class TShape {
    public:
      virtual void Paint() = 0;
      virtual void Erase() = 0;
      /* ... */
  };

Notate l'assegnamento effettuato alle funzioni virtuali, funzioni di questo tipo vengono dette funzioni virtuali pure e l'assegnamento ha il compito di informare il compilatore che non intendiamo definire i metodi virtuali. Una classe che possiede funzioni virtuali pure e detta classe astratta e non e` possibile istanziarla; essa puo` essere utilizzata unicamente per derivare nuove classi forzandole a fornire determinati metodi (quelli corrispondenti alle funzioni virtuali pure). Il compito di una classe astratta e` quella di fornire una interfaccia senza esporre dettagli implementativi. Se una classe derivata da una classe astratta non implementa una qualche funzione virtuale pura, diviene essa stessa una classe astratta.
Le classi astratte possono comunque possedere anche attributi e metodi completamente definiti (costruttori e distruttore compresi) ma non possono comunque essere istanziate, servono solo per consentire la costruzione di una gerarchia di classi secondo un ordine incrementale:

  class TShape {
    public:
      virtual void Paint() = 0; // ogni figura puo` essere
      virtual void Erase() = 0; // disegnata e cancellata!
  };

  class TPoint : public TShape {
    public:
      TPoint(int x, int y) : X(x), Y(y) {}

    private:
      int X, Y;                 // coordinate del punto
  };

  void TPoint::Paint() {
    /* ... */
  }

  void TPoint::Erase() {
    /* ... */
  }

Non e` possibile creare istanze della classe TShape, ma la classe TPoint ridefinisce tutte le funzioni virtuali pure e puo` essere istanziata e utilizzata dal programma; la classe TShape e` comunque ancora utile al programma, perche` possiamo dichiarare puntatori di tale tipo per gestire una lista di figure.

Pagina precedente - Pagina successiva