Newsgroup: it.comp.lang.c++
Titolo: Controvarianza sul tipo del risultato

Cari amici, sto cercando di capire questi concetti e quindi ho scritto
questo esempio che però non viene compilato. Questo significa che la
controvarianza sul tipo del risultato non è ammessa in C++ oppure
semplicemente che ho sbagliato qualcosa? Ecco il codice:
#include <iostream>
class B1 {};
class D1: public B1 {};
class B2
{
    public:
        virtual D1 *func() { std::cout << "B2::func()" << std::endl; }
};
class D2: public B2
{
    public:
        B1 *func() { std::cout << "D2::func()" << std::endl; }
};
int main()
{
    B2 *p1 = new B2;
    B2 *p2 = new D2;
    B1 *p3 = p1 -> func();
    B1 *p4 = p2 -> func();
    delete p2;
    delete p1;
}
Un'altra domanda: la covarianza/controvarianza si applica solo quando i
tipi coinvolti sono puntatori, giusto? Altrimenti non avrebbe senso
parlare di sostituibilità, dico bene?
EMG


Possono anche essere referenze.
Manlio Perillo

 parlare di sostituibilitą, dico bene?
o puntatori o riferimenti
a presto
	Lorenzo
-- 
+-----------------------------------------------------+
|  Lorenzo Bettini          ICQ# lbetto, 16080134     |
|  PhD student in Computer Science                    |
|  Florence - Italy         (Linux User # 158233)     |
|  Home Page        : 
http://w3.newnet.it/bettini
     |
|           
http://infostud.dsi.unifi.it/~bettini
     |
|  Mail Home        : 
lorenzo...@penteres.it
     |
|  Mail University  : 
bet...@dsi.unifi.it
            |
|  
http://www.mokabyte.it
       Java on line journal  |
|  
http://music.dsi.unifi.it
         XKlaim language  |
|  
http://www.gnu.org/software/java2html
 & cpp2html   |
+-----------------------------------------------------+

 Possono anche essere referenze.
Ah, certo! Chiaro ed ovvio, grazie.
EMG

 Non e' ammessa in C++ e meno male: altrimenti non avresti la type safety
Bene, allora comincio a capirci qualcosina. Grazie per tutta la
spiegazione.
EMG

parlare di sostituibilità, dico bene?
Credo che questo dipenda dal senso dato al termine
"sostituibilita`". 
In un modello come quello del C++ (in cui non e` ammesso
ridefinire un attributo e in cui si faccia ricorso alla
controvarianza), il tipo restituito da una funzione (covariante)
"riempirebbe" l'eventuale l-value (eventualmente di classe base)
con eventuale perdita di stato specifico (del tipo restituito) e
sicuramente di comportamento specializzato.
Discorso analogo vale per i parametri della funzione, in quanto 
prenderesti realmente un parametro di classe base pur essendo
utilizzato un tipo derivato.
In pratica se ridefinisci la funzione, la covarianza sul risultato
ti impone come codominio un sottoinsieme di quello originario
(quindi restituisci al piu` gli stessi elementi della funzione di
partenza).
La controvarianza sui parametri garantisce che la
funzione eventualmente ridefinita abbia come dominio un sovrainsieme
di quello di partenza (e che quindi possa prendere almeno
tutti i possibili parametri della funzione di partenza).
In questo senso la controvarianza consente di verificare il principio
di sostituibilita`.
La limitazione relativa all'uso di soli puntatori ti permette invece
di non perdere le caratteristiche peculiari dei tipi effettivamente
utilizzati. E` chiaro che questo non ti garantisce comunque la
sostituibilita` dal punto di vista del comportamento poiche`
pur mantenendo un prototipo coerente la funzione ridefinita
potrebbe comunque fare qualcosa di semanticamente molto diverso.
La covarianza (nel senso di 2 dell'articolo di Pescio) come ampiamente
discusso non e` in generale type safe e richiede un controllo dei tipi
a run time.
Paolo

 Non e` ammessa dal C++ (e da nessun linguaggio OO che io sappia).
Grazie di tutto. Molto chiaro.
EMG

 Un'altra domanda: la covarianza/controvarianza si applica solo quando i
tipi coinvolti sono puntatori, giusto? Altrimenti non avrebbe senso
parlare di sostituibilità, dico bene?
potrebbero anche essere dei reference
-- 
Posted from [213.82.54.99] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Non e` ammessa dal C++ (e da nessun linguaggio OO che io sappia).
Smalltalk l'ammette eccome.  O che Smalltalk non e` piu` OO, adesso...?-)
C'e` una "simpatica" tendenza, fra i patiti dei linguaggi a tipizzazione
statica, a dare per scontato che la tipizzazione statica sia una delle
caratteristiche "indispensabili" di un certo paradigma -- si vedono
delle affermazioni, sui gruppi di Functional Programming, che sembrano
implicare che Erlang o Scheme (due dei piu` diffusi linguaggi FP) non
sono FP (perche` hanno tipizzazione dinamica), e analogamente, sui
gruppi di OO, si vedono affermazioni che sembrano implicare che Python
o Smalltalk, linguaggi OO a tipizzazione dinamica, "non sono OO"...:-).
Per fortuna, nel caso dell'OO, lo stesso *termine* "object-oriented"
e` stato *inventato* dal creatore di Smalltalk, per cui e` facile far
accettare a tutti che l'OO non implica affatto lo static-typing -- dovreste
vedere invece le flamewar sul tema sui gruppi di FP...:-).
Alex

He's back! 
E per niente arrugginito, direi! Pensare che per la nostalgia mi ero
persino comprato un libro su Python...
Ciao,
Nicola

o Smalltalk, linguaggi OO a tipizzazione dinamica, "non sono OO"...:-).
Ma non erano i "patiti" di smaltalk che un tempo affermavano che i
veri linguaggi OO fossero solo quelli con run time type checking e
con metodi sempre e rigorosamente virtuali?
Paolo
p.s.
  bentornato!

 Smalltalk l'ammette eccome.  O che Smalltalk non e` piu` OO, adesso...?-)
Evvai!!! Riabbiamo l'Alex!!! :-)
EMG