Se state usando Visual C++ 2005, vi sarete probabilmente accorti che l'ambiente non è ancora del tutto completo. Esistono alcune limitazioni nella gestione del progetto (file di risorsa, file di soluzione, etc.). Non so se queste rimarranno limitazioni del prodotto Express definitivo, ad ogni modo potete ovviare a questi problemi scrivendo manualmente il file di progetto e vcbuild.exe per compilarlo. Qui potete trovate lo schema XML:
http://msdn2.microsoft.com/library/y4sy8216(en-us,vs.80).aspx
Il designer è decisamente migliorato, tuttavia, a mio parere, genera un pessimo codice. Sarebbe stato importante, per lo meno, che separasse le implementazioni dei metodi (in particolare, del costruttore e dei delegati che gestiscono gli eventi) dalla loro dichiarazione, come è comune fare nei progetti C/C++.
Tra le note completamente positive, potrei citare l'intellisense, perfettamente funzionante, la comoda "start page" e le performance complessive dell'ambiente di sviluppo, che risulta decisamente più veloce e leggero di Visual Studio 2003 Professional o di altri IDE per Java.
Il lavoro svolto da Sutter, Lipman e colleghi è veramente eccezionale. Ora manca solo la standardizzazione da parte dell'ECMA. La nuova sintassi è un'ottimo compromesso tra eleganza, integrazione con le funzionalità offerte dal CLR e mantenimento degli idiomi tipici del C++. Confrontando alcune semplici classi che ho scritto sia in C#, sia in C++/CLI l'impressione è che il secondo linguaggio abbia dato al mio codice una forma estremamente più elegante e mantenibile. I motivi principali sono i seguenti:
1. Distinzione tra dichiarazione (in un file header) e implementazione. In questo modo, guardando il file header risulta immediatamente visibile com'è strutturata una classe, senza bisogno di scorrere tra tutte le linee di codice. Ok, il class viewer fa anch'esso un ottimo lavoro in merito, ma supportare questo stile di programmazione a livello di codice, secondo me è molto importante.
2. Tipi valore e tipi riferimento sono dichiarati e costruiti in maniera diversa. Questo, a mio parere è fondamentale su una piattaforma come il CLR che, a differenza di Java, ci offre la possibilità di creare tipi valori customizzati (struct in C#, value class o value struct in C++/CLI). La scelta, inoltre, di distinguere gli operatori "gcnew" e "^" da "new" e "*" è veramente ben pensata.
3. I tre operatori per l'accesso a membro "::", "->" e "." aggiungono chiarezza e auto-esplicatività al codice.
4. Esistono i costruttori statici! Spesso rimpianti in Java e C# quando si deve inizializzare in maniera non banale i membri statici di una classe.
5. Come già fatto notare da Andrea il compilatore C++/CLI espande automaticamente le proprietà per le quali non sono dichiarati i metodi get/set (sostanzialmente inserisce un membro privato e l'implementazione banale di get/set).
6. La possibilità di dicharare lo specificatore di accesso (public, private, protected, internal) su una serie di dichiarazioni successive ci evita un po' di battitura e favorisce il raggruppamento dei membri (buona norma da molti utilizzata).
7. Viva la standard template library! Ora esiste una STL per il CLR... personalmente System::Collections non mi è mai piaciuta...
More info and examples to come...
Inoltre il team di cl.exe ha svolto un gran lavoro affinchè le stesse possibilità di ottimizazzione che anni di esperienza hanno permesso di attribuire al compilatore C++ ora possano venire applicate anche al codice gestito. Naturalmente esistono delle differenze, dovute al fatto che il CLR è una macchina virtuale stack-based, ma il codice IL generato da cl.exe è mediamente più performante di quello prodotto da csc.exe o vbc.exe.