Dr. Carlo Pescio Lo Standard ANSI/ISO per il Linguaggio C++

Pubblicato su Computer Programming No. 42

Come molti lettori sapranno, è imminente il rilascio dello standard ANSI/ISO per il linguaggio C++. Per molti, l'organizzazione e l'attività del comitato di standardizzazione restano però argomenti sconosciuti. In questo breve articolo vedremo l'organizzazione del comitato ed alcuni esempi di discussione tratti dai verbali di diverse sedute.

Organizzazione

Esistono di fatto due diversi comitati di standardizzazione, ovvero l'American National Standards Institute ANSI-X3J16 e l'International Standards Organization ISO-WG21, che cooperano in uno sforzo congiunto ANSI/ISO; in effetti, il comitato ANSI svolge gran parte delle discussioni preliminari, mentre il comitato ISO si occupa più che altro della ratifica delle diverse mozioni proposte dal comitato ANSI.

I comitati si riuniscono tre-quattro volte l'anno, e ad ogni riunione partecipano in media settanta rappresentanti di diverse organizzazioni, il cui ruolo e la cui preparazione tecnica è spesso molto differente, comprendendo diverse figure dai teorici dei linguaggi agli implementatori di compilatori o di librerie, dagli utenti del linguaggio agli esperti di standardizzazione. Tutti i partecipanti sono volontari, e non ricevono alcun compenso per il lavoro svolto all'interno del comitato di standardizzazione.

Poiché il C++ conta ormai numerose estensioni (se paragonato al linguaggio descritto da Stroustrup in "The C++ Programming Language, 2nd. ed.") e considerando che anche le librerie fanno parte dello standard, è evidente che lo sforzo di standardizzazione doveva essere suddiviso in diverse sezioni: all'interno del comitato esistono quindi diversi gruppi di lavoro, ognuno facente capo ad un coordinatore. Attualmente i gruppi, suddivisi per argomento di competenza, sono:

- Sintassi formale

- Funzionalità base del linguaggio (Core Language)

- Ambiente (preprocessore, linker, ecc)

- Compatibilità con il linguaggio C

- Estensioni al linguaggio

- Internazionalizzazione (in particolare si occupa del set di caratteri esteso)

- Librerie

- Dettagli (Small Issues, si occupa di aspetti peculiari, di cui daremo un esempio più avanti; dal 1993 è stato diviso in due gruppi indipendenti)

- Editoria (si occupa delle correzioni e della stesura del draft).

Naturalmente, vi è una forte interazione tra i diversi gruppi, che durante le riunioni espongono il risultato del lavoro svolto, di norma con una premessa che permetta a tutti di seguire più facilmente le ragioni di base e le strade intraprese. Eventuali proposte vengono normalmente sottoposte a votazione da parte di tutti i membri presenti aventi diritto; corrispondentemente, ogni nuova problematica viene immediatamente assegnata ad uno dei gruppi di lavoro, che esporrà i risultati in una successiva riunione.

Risultati

Molti dei risultati ottenuti dal comitato di standardizzazione non emergono immediatamente dalla lettura della proposta di standard, ed alcuni non saranno neppure visibili nei molti libri che seguiranno il rilascio dello standard. Si tratta spesso di definire in modo preciso certi termini, eliminare possibili ambiguità da alcune frasi, chiarire il comportamento in situazioni poco consuete, e così via; in molti casi, le discussioni vertono su argomenti che gli sviluppatori tendono a dare per scontati.

Si tratta nondimeno di un lavoro di estrema importanza, sia per chi sviluppa compilatori, che ha così a disposizione una descrizione più precisa del linguaggio, sia per gli utenti del linguaggio, che possono fare riferimento allo standard per risolvere problemi di portabilità del codice, o di legalità o meno di un costrutto, anziché affidarsi totalmente al responso del compilatore utilizzato.

Proprio per l'ampio pubblico interessato allo standard, la definizione del linguaggio è data in linguaggio naturale, pur cercando di eliminare possibili ambiguità e ridondanze; non è invece prevista una definizione formale, come è avvenuto ad esempio con Ada di cui esiste una Semantica Denotazionale ed una Semantica Operazionale Strutturale. Questo potrebbe in effetti impedire l'adozione del linguaggio in alcuni progetti critici, ad esempio in ambito militare, ma non costituisce un reale problema per l'utente medio del linguaggio, poco avvezzo invece ai metodi formali.

Per meglio illustrare le attività del comitato di standardizzazione, di seguito ho riportato alcuni esempi degli argomenti di discussione, tratti dai verbali di alcune sedute degli ultimi anni.

Dallas, 1991. Gruppo Sintassi Formale. Sull'uso di < > per delimitare i parametri dei template.

Tom Pennello osserva che l'uso di < e > come delimitatori per i template pone alcuni problemi a livello di parsing:

1. Due delimitatori consecutivi >> possono essere scambiati per un singolo operatore di shift
2. I parametri attuali di un template non possono avere forma a > b
3. Il parser deve sapere se un identificatore è un nome di template, per riconoscere costrutti come new T < ...
4. Vi è una ambiguità di ri-dichiarazione in const T ;

Pertanto, Pennello propone di utilizzare le normali parentesi ( ) invece di < > per delimitare gli argomenti dei template; ciò risolverebbe i problemi (1) e (2) ma non (3) o (4). Fa notare che si potrebbero usare anche [ ] o { } in luogo di ( ). Alternativamente, suggerisce di adottare ( ) ma di lasciare < > come anacronismo.

Bjarne Stroustrup sostiene che usare < > sia comunque la soluzione migliore. Le ragioni per usare ( ) sono tutte relative all'implementazione dei compilatori, mentre le ragioni per usare < > sono a livello di leggibilità del codice. Stroustrup garantisce di avere esperienza personale con entrambe le notazioni, e non ha dubbi su quale delle due è più semplice da usare per gli umani, anche se non per i compilatori.

Mike Vilot conferma che ( ) sono già pesantemente overloaded, e che ad esempio alcuni utenti Ada si lamentano dell'eccessivo uso di ( ); è sua opinione che risolvere il conflitto sia un piccolo costo da pagare rispetto al vantaggio di usare < >.

Dan Saks suggerisce di mantenere < > e di restringere fortemente la sintassi dei parametri attuali per i template, limitandola ad esempio ad identificatori e letterali.

Andrew Koenig osserva che usare ( ) rimuove solo i problemi (1) e (2) e che (2) è peraltro molto raro nel codice reale.

La proposta di modificare la sintassi viene rifiutata con 7 si, 26 no, 5 astensioni.

La restrizione del linguaggio per evitare ambiguità viene assegnata al gruppo sulle Funzionalità di Base (18 voti, contro i 5 voti per il gruppo Sintassi Formale).

Toronto, 1992. Gruppo Estensioni. Overloading degli operatori basato su tipi enumerati.

Dag Brück presenta la sua proposta intesa a permettere l'overloading degli operatori basato sui tipi enumerati. Spiega le ragioni della sua proposta con il seguente esempio:

enum status { bad, awful, hopeless };

f(int);

f(status);

Basandosi sul frammento di codice dato, f(bad) chiama f(status), ma f(bad|awful) chiama f(int), in quanto bad|awful è una espressione di tipo int. Ovvero, è possibile avere l'overloading della funzione f, ma chiamare f con un'espressione che coinvolge gli enumerati è un potenziale pericolo, in quanto chiama comunque f(int).

[seguono altri esempi dell'utilità dell'overloading, ad esempio la ridefinizione di ++ su un tipo enumerato]

La proposta di estensione viene approvata con "molti si", nessun no, 5 astenuti.

Portland, 1993. Gruppo Dettagli. Friend e classi locali.

Josée Lajoie presenta un argomento di discussione del gruppo, relativo al seguente problema: può una funzione friend di una classe locale essere definita in tale classe?

Jonathan Shopiro osserva che, se tale definizione fosse lecita, nel seguente frammento di codice:

void func() {

static int x = 3;

class C {

friend int g() { return x; }

};

};

int g();

int k() { g(); }

g() potrebbe essere chiamata prima della prima esecuzione di func, quindi in un momento in cui x può non essere inizializzata.

Il gruppo propone quindi di aggiungere la seguente restrizione allo standard: "Se una classe locale dichiara una funzione globale come friend, tale funzione globale non può essere definita nello scope della classe locale".

La restrizione viene approvata con "molti si", 4 no, nessun astenuto.

Josée Lajoie presenta altre dichiarazioni friend discutibili [esempi vari omessi]; Martin O'Riordan ed Alan Sloane chiedono al Gruppo Dettagli di considerare l'opportunità di bandire tutti i casi tranne quelli realmente utili.

Conclusioni

Come potrete facilmente verificare, molte delle modifiche apportate dallo standard sono già state implementate dai produttori di compilatori; è quindi questione di mesi o settimane prima che versioni commerciali di compilatori ANSI C++ siano disponibili sul mercato.

Reader's Map

Molti visitatori che hanno letto questo articolo hanno letto anche:

Biografia
Carlo Pescio svolge attività di consulenza in ambito internazionale sulle metodologie di sviluppo Object Oriented e di programmazione in ambiente Windows. È laureato in Scienze dell'Informazione, membro dell'Institute of Electrical and Electronics Engineers Computer Society, dei Comitati Tecnici IEEE su Linguaggi Formali, Software Engineering e Medicina Computazionale, dell'ACM e dell'Academy of Sciences di New York. Può essere contattato tramite la redazione o su Internet come pescio@programmers.net