|
 |
 |
 |
 |
|
Perché non esiste un linguaggio di programmazione perfetto? |
|
|
|
di davide panceri "programmazione.it"
Andrew Koenig e Barbara E. Moo spiegano, in un articolo per il C/C++ User Journal di agosto, come mai i linguaggi di programmazione (in questo caso il C++) non siano perfetti e presentino stranezze e incongruità apparentemente inspiegabli, che suscitano reazioni ovvie e spontanee, come le classiche domande "Perché nessuno ha eliminato questa cosa?", "Perché il linguaggio non ha questa caratteristica?".
Andrew Koenig e Barbara E. Moo spiegano, in un articolo per il C/C++ User Journal di agosto, come mai i linguaggi di programmazione (in questo caso il C++) non siano perfetti e presentino stranezze e incongruità apparentemente inspiegabli, che suscitano reazioni ovvie e spontanee, come le classiche domande "Perché nessuno ha eliminato questa cosa?", "Perché il linguaggio non ha questa caratteristica?".
Le risposte a queste domande cambiano da un linguaggio all'altro, e in genere si capiscono meglio conoscendo il contesto in cui un linguaggio nasce: una conoscenza almeno parziale di queste stranezze, sotterfugi e scappatoie potrebbe anche favorire un migliore utilizzo delle possibilità offerte da ciascun linguaggio. Ad esempio, dal momento che i compilatori Fortran provvedono ad ottimizzare il codice quando compilano, i programmatori dovrebbero preoccuparsi maggiormente della chiarezza e leggibilità del codice.
Da questo articolo emerge soprattutto l'importanza del confronto con la velocità del C, e della compatibilità con il codice esistente, che hanno causato il passaggio di qualche stranezza nel nuovo nato C++. I casi menzionati dagli autori riguardano tra gli altri i limiti degli array, le variabili non inizializzate, le funzioni non virtuali per default e gli array dinamici.
La mancanza del controllo sui limiti di array e vector è dovuta alla necessità di competere con il C quanto a velocità di esecuzione, aspetto presumibilmente più sensibile qualche anno fa e che avrebbe probabilmente compromesso le prestazioni dei programmi in C++, impedendo l'affermazione del nuovo linguaggio: chi avrebbe perso tempo e fatica per imparare il C++ e rimetterci in velocità di esecuzione?
La competizione tra i due linguaggi esiste anche laddove non c'è una controparte diretta, e il codice C non potrebbe essere facilmente tradotto e confrontato in C++, precisamente nei vector della Standard Library di C++. Anche qui non esiste di default il controllo sui limiti del vector, e sempre per un valido motivo: un netto e inevitabile calo di prestazioni (nonostante la maggiore sicurezza) avrebbe spinto molti programmatori a evitare l'uso dei vector, e magari del C++ in toto. I progettisti comunque hanno raggiunto un compromesso, dal momento che esistono due modi di accedere all'elemento i-esimo di un vector: v[i], in stile C, e v.at(i), che lancia un'eccezione se i non si trova nell'intervallo previsto.
Ancora la concorrenza con il C e la coesistenza con programmi scritti in quel linguaggio, determina la possibilità di creare variabili senza inizializzarle. Gli imprevedibili effetti collaterali a cui questa permissività può dare luogo rendono difficile definire un comportamento ragionevole in casi di uso non corretto di variabili non inizializzate: meglio terminare il programma, stampare il valore incriminato, o cos'altro? Questo rimane un grosso problema, dal momento che si possono introdurre nel codice bachi non facili da scoprire, di cui l'articolo fornisce un semplice esempio.
Un altro aspetto che può provocare qualche problema è la compatibilità non con il C, ma con le prime versioni di C++, come si vede nella persistenza di variabili contatore al di fuori del ciclo for, come in questo esempio:
for (int i = 0; i != n && a[i] != x; ++i) ;
if (i != n) { /* ... */ }
il fatto che i continui ad esistere anche al termine del ciclo for può essere comodo, ma può dare luogo a qualche problema, come la doppia definizione della variabile se si fa più di un confronto. Con la standardizzazione del linguaggio il problema dovrebbe essere risolto da qualche anno, eppure ancora si trovano compilatori che lavorano con il vecchio stile di programmazione, estendendo la validità della variabile contatore al di fuori del ciclo for.
Le ultime due stranezze esaminate riguardano la presenza di due forme della funzione delete, di cui una per gli array, e il fatto che le funzioni membro delle classi non sono virtuali per default. Nel primo caso c'è di mezzo la solita compatibilità con il C, mentre il secondo comportamento di default del C++ favorisce la velocità, anche se a rischio di errori dal momento che i distruttori di solito non devono essere virtual.
Per approfondire l'argomento, oltre all'articolo in questione, rimando ad un commento su quest'altro, laddove si dice che con il C++ capita a volte di doversi spremere sul modo migliore di imbrogliare il compilatore, invece che sulla soluzione del problema. Vero, ma forse conoscendo i motivi la cosa potrebbe apparire meno antipatica. |
|
 |
 |
|
 |
|
|
