Con molto affanno torno sul VC++ Day ... le due giornate passate con April, Ronald e Nikola sono state entusiasmanti.
Non ho memoria di un evento su VC++ e se c'erano voci che il C++ stesse per andare in cantina, all'evento sono state smentite con i fatti. Circa 140 persone, 55 tester e 16 PM si occupano di questo gioiello che serve a sviluppare il 95% del codice prodotto da Microsoft.
Riassumere tutto sarebbe veramente lunghissimo e quindi mi terrò argomenti per futuri blog, dopo aver approfondito i singoli punti, però alcune cose mi fa piacere ricordarle:
- Adeguamento allo standard ISO. Questo è un punto importante perchè permette di mettere al sicuro il nostro codice sorgente. Spesso i sorgenti VC++ sono algoritmi privi di interfaccia grafica che possono veramente sopravvivere a lungo, a priori del sistema operativo o delle tecnologie che li circondano. Usare un compilatore standard significa che con le future versioni non ci saranno sorprese nel compilare il nostro codice.
Spesso questo punto mette in crisi chi migra da VC++ 6.0 che non era affatto aderente allo standard, ma tra le altre cose si guadagna la possibilità di usare librerie note come Boost e Loki.
- Ottimizzazioni. Solo ricompilando il codice con le nuove ottimizzazioni si guadagna in performance fino al 30% rispetto a VC++ 6.0 e cifre simili anche da VC++ 2003 ... per una ricompilata non è male :-)
Le ottimizzazioni ora tengono conto dell'intero codice e non sono più applicate solo sui singoli file obj.
- Supporto del compilatore per la compilazione parallela su più CPU o su più Core in una singola CPU
- Supporto del compilatore alle specifiche OpenMP di cui avevo visto una demo della Intel allo scorso TechEd. In pratica con la direttiva:
#pragma omp parallel for
for(int i=0; i<=n; ++i) {a[i] = b[i] + c[i] }
si ottimizza l'esecuzione del loop su più thread contemporaneamente.
- Profilazione statica del codice. Questa analisi permette di ottimizzare il codice sulla base di un run di prova. Si lancia l'applicazione in una modalità particolare usando le sole funzionalità critiche, quelle per cui vogliamo il massimo della performance. I dati collezionati da questa modalità vengono poi usati dal compilatore per ottimizzare la compilazione vera e propria.
- Sempre una profilazione statica del codice permette l'individuazione di potenziali problemi, vulnerabilità, etc. suggerendo se possibile la fix da adottare.
- Supporto del compilatore managed e unmanaged per la compilazione a 64bit
- Side-by-side libraries del CRT (e non solo) per evitare il più che noto DLL Hell
- Supporto all'attach del debugger a più processi oltre che a più thread come già fattibile in VS.NET 2003
- Unico ambiente di sviluppo sia per la piattaforma Full che quella embedded
- Secure version delle librerie CRT (tanto per intenderci quelle usate per la XP SP2 e Win2K3 SP1). Il codice va rivisto ma con queste librerie si evitano i buffer overrun e quindi ne vale la pena. In molti casi non è necessario modificare nulla grazie ad una speciale versione templated delle funzioni che permette di 'dedurre' la dimensione del buffer se questa viene allocata nello stack locale.
- Nuova sintassi C++/CLI in fase di standardizzazione ECMA ed ISO. Il nuovo standard è molto più semplice da usare e permette di usare con semplicità le facilities di una piattaforma costruita sulla Common Language Infrastructure (standard ECMA). Grazie alla riga di comando /CLR si compila secondo la nuova sintassi.
Per chi ha usato le managed extensions, sarà disponibile un tool di conversione automatizzata che lo stesso Stan Lippman ci ha mostrato lo scorso Aprile a Redmond.
- Linker di VC++ potrà costruire immagini miste (file come le dll) con codice managed (generato non solo da C++/CLI ma anche da C# o altri linguaggi) ed unmanaged. Questo può tornare utile a tutti coloro che volessero linkare in un unico assembly da VS.NET codice IL sviluppato in linguaggi diversi.
- Deterministic Finalization. In pratica il distruttore delle classi C++ non è mappato come in C# sulla Finalize ma sulla Dispose. Questo consente l'implementazione automatica del pattern Dispose risparmiando non pochi grattacapi vista la complessità di quel pattern.
- Possibilità di inserire le Winform (ed in futuro Avalon) in progetti MFC o WTL, grazie alla creazione di immagini miste managed/unmanaged. Per esempio MFC può usere le winform al posto di una classica CView senza perdere il routing dei messaggi, etc..
- ... sicuramente me ne sto dimenticando molte altre ...
Tutto questo per non parlare dell'IDE che fa veramente invidia anche a C#.... more to come ...