[C++] Uno sguardo al futuro del C++

[kernel::panic]

Segnalo a tutti coloro che usano il C++ per lavorare/smanettare/imparare il seguente articolo che parla delle caratteristiche del nuovo standard del C++ (nome in codice C++0x) che sostituirà l'attuale (C++03, anche se molti compilatori usano ancora il precedente C++98) entro il 2010.

http://en.wikipedia.org/wiki/C%2B%2B0x

L'obiettivo è quello di migliorare e potenziare il linguaggio mantenendo il più possibile la compatibilità con l'attuale C++ e col C:

* Maintain stability and compatibility with C++98 and possibly with C;
* Prefer introduction of new features through the standard library, rather than extending the core language;
* Prefer changes that can evolve the programming technique;
* Improve C++ to facilitate systems and library design, rather than to introduce new features only useful to specific applications;
* Increase type safety by providing safer alternatives to current, unsafe techniques;
* Increase performance and the ability to work directly with hardware;
* Provide proper solutions for real world problems;
* Implement "zero-overhead" principle (additional support required by some utilities must be used only if the utility is used);
* Make C++ easy to teach and to learn without removing any utility needed by expert programmers.

Tra le varie novità spiccano:

- Rvalue Reference: velocizza le funzioni che ritornano delle classi, permettendo di copiarne il puntatore al contenuto, invece che la momoria del contenuto stesso... è spigato da cane, ma sul documento è meglio
- Espressioni lambda, determinazione automatica del tipo, foreach... mi sembrano le specifiche del C# 3.0
- Classe per incapsulare un puntatore: è comoda per sapere se il puntatore è già stato eliminato (delete) e quindi evitare un crash
- Nuove stringhe wide: oltre a L"" ci sarà u"", u8"" e U"" ... buon divertimento con le macro
- Introduzione dell'header <regex> per le regular expressions
- Vari miglioramenti e potenziamenti dei template (tra cui la possibilità di passare un numero qualsiasi di argomenti-tipo)
- Facilitazioni sui thread con nuove classi, tipo i mutex, aggiunte (finalmente!) alla libreria
- E molto altro ancora...
- In passato avevo letto che si pensava di introdurre anche un garbage collector, ma è stato rimandato (meglio così! ... preferisco usare il C# o il Java se voglio la gestione automatica della memoria)

Ciao e buona lettura

[tomminno]

Originariamente inviato da kernel::panic

Tra le varie novità spiccano:

- Rvalue Reference: velocizza le funzioni che ritornano delle classi, permettendo di copiarne il puntatore al contenuto, invece che la momoria del contenuto stesso... è spigato da cane, ma sul documento è meglio

Questo renderà finalmente usabili i riferimenti anche in C++.
Si potrà restituire il riferimento ad una variabile locale.

- Espressioni lambda, determinazione automatica del tipo, foreach... mi sembrano le specifiche del C# 3.0

Le lambda esistevano già nelle boost sono state estese e inglobate, il for_each esiste da sempre.

- Classe per incapsulare un puntatore: è comoda per sapere se il puntatore è già stato eliminato (delete) e quindi evitare un crash

Se non sbaglio auto_ptr dovrebbe diventare deprecato, non ricordo il nome della nuova classe, ma soprattutto potrà essere usata anche con i contenitori della STL, mentre auto_ptr assolutamente no.

- Vari miglioramenti e potenziamenti dei template (tra cui la possibilità di passare un numero qualsiasi di argomenti-tipo)

Più che altro sarà possibile specificare come in C# restrizioni sul tipo del template.

- Facilitazioni sui thread con nuove classi, tipo i mutex, aggiunte (finalmente!) alla libreria

Questo mi sembrava di aver capito che non lo volessero aggiungere alla libreria. Comunque meglio così.
C'erano in ballo anche blocchi di istruzioni atomiche con atom se non ricordo male.

Si in questa nuova versione dello standard ci sono molte modifiche interessanti.
Influenzate certamente da personaggi come Herb Sutter che hanno preso spunto da quello che è stato fatto di buono col C#.

[kernel::panic]

Originariamente inviato da tomminno

Le lambda esistevano già nelle boost sono state estese e inglobate, il for_each esiste da sempre.

In effetti, parecchie delle nuove features provengono da concetti sviluppati nelle boost.

Gli sviluppatori delle boost spingono anche per introdurre nella libreria del c++ le loro funzioni per la gestione (multipiattaforma) del file-system.

[cionci]

Originariamente inviato da tomminno

Questo mi sembrava di aver capito che non lo volessero aggiungere alla libreria. Comunque meglio così.
C'erano in ballo anche blocchi di istruzioni atomiche con atom se non ricordo male.

Se inseriscono queste cose allora devo inserire anche i thread, a rigor di logica...

[gugoXX]

Originariamente inviato da cionci

Se inseriscono queste cose allora devo inserire anche i thread, a rigor di logica...

Gia', cosi' poi puoi chiudere anche quelli, se non inziano con [C++]
Ok, basta, torno a casa.

[tomminno]

Originariamente inviato da cionci

Se inseriscono queste cose allora devo inserire anche i thread, a rigor di logica...

Avevo letto che tra tutte le novità da includere, vista la mancanza di tempo, i thread non erano tra le cose prioritarie (perchè sono pratiche già consolidate), quindi rischiano di rimanere fuori dallo standard.
Vedremo.

[cionci]

Allora mi domando che senso abbia inserire le mutex

[kernel::panic]

Sul documento di wiki c'è scritto che verrà aggiunta una classe per la gestione dei thread (come è corretto che sia)... farebbe ridere avere mutex e semafori e poi dover lavorare con la _beginthread()

Cmq speriamo che per mancanza di tempo non facciano castronate!

[tomminno]

Originariamente inviato da cionci

Allora mi domando che senso abbia inserire le mutex

Purtroppo stanno facendo le corse per pubblicare lo standard nel 2009 e sono già in ritardo, doveva già esserci un documento finale.
Lo stato di avanzamento uscito dall'ultimo meeting è disponibile qui

[Antares88]

da niubbo colossale mi domando:

1) chi decide le specifiche della nuova versione di un linguaggio di programmazione
2) come vengono implementate all'atto pratico ? vengono distribuiti nuovi compilatori ?
3) quanto si riesce a modificare un linguaggio già esistente e solido come il c++ ? e soprattutto, ha senso farlo ? ha senso aggiungere qualche feature in più e dannarsi per anni cercando di risolverne i difetti e superarne i limiti ?
4) quali sono i limiti odierni del c++ e i suoi punti di forza rispetto agli altri linguaggi adottati massicciamente al giorno d'oggi (Java, Python, C e derivati, etc...)?

[tomminno]

Originariamente inviato da Antares88

da niubbo colossale mi domando:

1) chi decide le specifiche della nuova versione di un linguaggio di programmazione

Nel caso di linguaggi come C e C++, il comitato che si occupa di gestire lo standard.
Nel caso di C# o Java invece lo sviluppo è deciso dalle rispettive aziende che possono fare quello che vogliono.
ISO prevede che uno standard venga rivisto periodicamente ogni 5 anni per "minor revision" e 10 anni per "major revision".
Per l'appunto siamo a 10 anni dal precedente standard C++ (che era già stato rivisto nel 2003).
Anche il C ha avuto diverse revisioni tanto che si parla di C89 e C99.

2) come vengono implementate all'atto pratico ? vengono distribuiti nuovi compilatori ?

L'implementazione dipende da chi adotta lo standard.
Si possono fare anche implementazioni non standard, come ha fatto Microsoft fino all'avvento di VS2005.

3) quanto si riesce a modificare un linguaggio già esistente e solido come il c++ ? e soprattutto, ha senso farlo ? ha senso aggiungere qualche feature in più e dannarsi per anni cercando di risolverne i difetti e superarne i limiti ?

Certo che ha senso modificare un linguaggio come il C++.
L'informatica è un mondo in continua evoluzione ed è bene che ci siano modifiche al linguaggio per mantenerlo attuale o superarne dei limiti.
Nel nuovo standard secondo me la novità più sostanziale è la "move semantic" che consentirà di evitare inevitabili copie di oggetti.

4) quali sono i limiti odierni del c++ e i suoi punti di forza rispetto agli altri linguaggi adottati massicciamente al giorno d'oggi (Java, Python, C e derivati, etc...)?

Secondo molti un limite è la mancanza di garbage collection (anche se volendo esistono delle librerie apposite).
Secondo me il vantaggio che hanno linguaggi come Java o C# è l'uniformità e vastità del framework.
Ad esempio per accedere ad un database, qualunque esso sia, in C# ricorri ad ADO.NET ovvero fai tutto nello stesso modo.
In C++ devi utilizzare le API specifiche di ogni DBMS e quindi studiarti il funzionamento di ognuna.
In parte sono anche gli IDE a rendere più usabile un linguaggio.
Ad esempio l'intellisense di VS fa una grande differenza quando vai a scrivere codice, quello per C++ non funziona molto bene.
Per molti aspetti l'intellisense di Code::Blocks funziona meglio.

[cionci]

Originariamente inviato da tomminno

Secondo me il vantaggio che hanno linguaggi come Java o C# è l'uniformità e vastità del framework.
Ad esempio per accedere ad un database, qualunque esso sia, in C# ricorri ad ADO.NET ovvero fai tutto nello stesso modo.
In C++ devi utilizzare le API specifiche di ogni DBMS e quindi studiarti il funzionamento di ognuna.

Perfettamente d'accordo e vedo che si va proprio in questo senso, l'integrazione di thread, mutex, semafori ed operazioni atomiche sicuramente potrebbe far fare già un notevole passo avanti. Certo è che se lo standard esce nel 2009, i compilatori compatibili verranno fuori minimo nel 2012

[tomminno]

Originariamente inviato da cionci

Perfettamente d'accordo e vedo che si va proprio in questo senso, l'integrazione di thread, mutex, semafori ed operazioni atomiche sicuramente potrebbe far fare già un notevole passo avanti. Certo è che se lo standard esce nel 2009, i compilatori compatibili verranno fuori minimo nel 2012

Se non sbaglio gcc è compatibile TR1, dinkumware ha già una libreria TR1.
Difficile vedere compilatori pienamente standard prima del 2010 e visto che dovrebbe essere l'anno d'uscita di Hawaii (VS2010), MS supporterà il nuovo C++ non prima del 2012 (sempre che non decida di abbandonare il C++ prima).

Purtroppo gli standard richiedono il loro tempo, ripagando però in stabilità nel tempo (contrariamente al C# che per il momento ha obbligato a buttare tutto il vecchio codice nel giro di 2 anni)

[kernel::panic]

Una cosa di cui sento la mancanza nel C++ è poter passare come callback alle API di sistema (in C) una funzione di classe non statica... In C# si può fare senza problemi (sia tra oggetti managed che unmanaged tramite P/Invoke), in C++ invece, o la callback è statica o ci si deve appoggiare ad accrocchi come questo: http://www.codeproject.com/KB/winsdk...k_adapter.aspx

Per quanto riguarda gli aggiornameti ai compilatori penso anche io che prima del 2010/11 non siano disponibili, le modifiche sono davvero tante...

[gugoXX]

Originariamente inviato da kernel::panic

Una cosa di cui sento la mancanza nel C++ è poter passare come callback alle API di sistema (in C) una funzione di classe non statica... In C# si può fare senza problemi (sia tra oggetti managed che unmanaged tramite P/Invoke), in C++ invece, o la callback è statica o ci si deve appoggiare ad accrocchi come questo: http://www.codeproject.com/KB/winsdk...k_adapter.aspx

Per quanto riguarda gli aggiornameti ai compilatori penso anche io che prima del 2010/11 non siano disponibili, le modifiche sono davvero tante...

Hai ragione. Quella soluzione pero' mi pare abbastanza elegante.
Il problema che vedo io e' che i programmatori C++ continuano ad ostinarsi a scrivere righe come

R Result = (_this->m_pObj->*_this->m_pfCB)(_this->m_UserData );

A me sinceramente piace proprio poco.
Ma cosa davvero cosi' tanto scrivere 5 righe di codice in piu', che molto probabilmente vengono risolte dal compilatore nello stesso identico modo di questa riga qui sopra?
Che vantaggio c'e'?

Secondo me qualcuno ogni tanto dovrebbe rileggere questo, che e' sempre attuale:
http://www.faqs.org/docs/artu/ch01s06.html
dove si trova
2. Rule of Clarity: Clarity is better than cleverness.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

Secondo me quella riga le viola tutte e 3.

[fek]

Originariamente inviato da gugoXX

Secondo me qualcuno ogni tanto dovrebbe rileggere questo, che e' sempre attuale:
http://www.faqs.org/docs/artu/ch01s06.html
dove si trova
2. Rule of Clarity: Clarity is better than cleverness.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

Secondo me quella riga le viola tutte e 3.

E aggiungo:
"Any fool can write code that a machine can understand, only good programmers can write code that a human can understand"

Io continuo a sostenere la necessita' di una Patente per legge prima di poter lanciare un compilatore.

Per chi vuole impratichirsi con qualche nuova feature c'e' ConceptGCC:
http://en.wikipedia.org/wiki/ConceptGCC

[cionci]

Che figata

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)

Addio vector< vector< list<int> > >::iterator

[tomminno]

Originariamente inviato da cionci

Che figata

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)

Addio vector< vector< list<int> > >::iterator

Vorrai dire addio vector<vector<list<int>>>::iterator

[cionci]

Preferisco lasciare uno spazio

[kernel::panic]

Originariamente inviato da gugoXX

Il problema che vedo io e' che i programmatori C++ continuano ad ostinarsi a scrivere righe come

R Result = (_this->m_pObj->*_this->m_pfCB)(_this->m_UserData );

A me sinceramente piace proprio poco.
Ma cosa davvero cosi' tanto scrivere 5 righe di codice in piu', che molto probabilmente vengono risolte dal compilatore nello stesso identico modo di questa riga qui sopra?
Che vantaggio c'e'?

Secondo me qualcuno ogni tanto dovrebbe rileggere questo, che e' sempre attuale:
http://www.faqs.org/docs/artu/ch01s06.html
dove si trova
2. Rule of Clarity: Clarity is better than cleverness.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

Secondo me quella riga le viola tutte e 3.

Purtroppo ho anche dei colleghi che a volte per fare "i fighi" scrivono 200 istruzioni su una riga.... poi però rido io quando c'è un baco o un puntatore a NULL e lo devono debuggare!