.NET

C++ Express: compatibilità, terminazioni di linea e codifica Unicode

Andrea Sansottera — Thu, 24 Nov 2005 16:33:00 GMT

Nelle ultime settimane mi sono imbattuto in tre features di Visual C++ Express. Sono caratteristiche poco "appariscenti", sulle quali sarebbe sprecato fare marketing, ma che si sono rivelate particolarmente utili. 1. E' possibile aprire vecchi progetti per Visual C++ 6. La procedura di conversione è pressochè indolore. Naturalmente, a causa degli allineamenti agli standard C++, è possibile che il nuovo compilatore generi messaggi di avviso, indicando che vengono usati costrutti sintattici deprecati. 2. Durante l'apertura di un file, l'editor rileva automaticamente se la convenzione di terminazione linea è consistente e, in caso contrario, propone un allineamento con lo standard per Windows, Unix o Macintosh. 3. Per impostazione definita i file sorgenti vengono salvati con codifica a 8 bit. Tuttavia, durante l'editing è possibile inserire caratteri Unicode. Al momento del salvataggio, verra chiesto se si vuole passare alla codifica Unicode a 16 bit o ad una diversa codifica ASCII estesa. E' inoltre possibile applicare la stessa scelta agli altri file del progetto.

NUnit 2.2.3

Andrea Sansottera — Sat, 19 Nov 2005 16:57:00 GMT

E' stato rilasciato NUnit 2.2.3, una nuova "iteration release", che include significative correzioni di bugs e nuove asserzioni. E' possibile leggere le release notes e scaricarlo a questo indirizzo. Sebbene sia stato compilato con Visual Studio 2003, funziona sul runtime di .NET 2.0. In realtà, anche con le versioni precedenti di NUnit, previa modifica del file di configurazione, non ho riscontrato problemi. La buona notizia è che, passando una semplice opzione a linea di comando, è ora possibile eseguire NUnit su una qualunque versione del framework disponibile sulla macchina. Altrimenti, per testare assembly creati con Visual Studio 2005, è sufficiente decommentare la sezione "startup" del file di configurazione "nunit-gui.exe.config". Happy testing! :)

Cleanup deterministico e finalizers in C++/CLI

Andrea Sansottera — Fri, 06 May 2005 02:05:00 GMT

Vediamo il seguente codice. Viene definito un reference type (typeid = Person), con un metodo publico, ReadMessage. Al suo interno viene utilizzato in tre modi diversi un oggetto di tipo System::IO::StreamReader, classe che implementa System::IDisposable. public ref class Person{public: Person (String^ name, String^ surname) { } void ReadMessage (String^ path) { Stream^ stream = (Person::typeid)->Assembly->GetManifestResourceStream (path);#ifdef MANUAL_DETERMINISTIC_CLEANUP // I manually call the distructor. StreamReader^ reader = gcnew StreamReader (stream); Console::WriteLine (reader->ReadLine ()); delete reader;#endif#ifdef AUTOMATIC_CLEANUP // Garabace collector will call the dispose methods before finalizing the reader. StreamReader^ reader = gcnew StreamReader (stream); Console::WriteLine (reader->ReadLine ());#endif#ifdef AUTOMATIC_DETERMINISTIC_CLEANUP // The compiler automatic inserts a method call to dispose. // The reference type instance has value semantic in this context. StreamReader reader (stream); Console::WriteLine (reader.ReadLine ());#endif }}; Decompiliamo con Reflector e vediamo come apparirebbe, nei diversi casi, il metodo ReadMessage se fosse scritto in C#. Nel primo caso reader è stato dichiarato come un handle, al quale abbiamo è stato assegnato un oggetto allocato sul managed heap tramite l'operatore gcnew . Dopo essere stato utilizzato, l'oggetto viene "distrutto" con l'operatore delete. Tale operatore viene sostanzialmente tradotto in un'eventuale chiamata al metodo Dispose (per gli oggetti il cui tipo implementa IDisposable*). Come noto, tale metodo nasce con lo scopo fondamentale di rilascare le risorse utilizzate dal nostro oggetto, non la memoria. La deallocazione sarà gestita dal garbage collector, che in questo caso, vedendo che è già stato eseguito il cleanup, non chiamerà il distruttore o l'eventuale finalizzatore **. Codice C#: public void ReadMessage(string path){ int num1; Stream stream1 = null; StreamReader reader1 = null; stream1 = typeof(Person).Assembly.GetManifestResourceStream(path); reader1 = new StreamReader(stream1); Console.WriteLine(reader1.ReadLine()); IDisposable disposable1 = reader1; if (disposable1 != null) { disposable1.Dispose(); num1 = 0; } else { num1 = 0; }} Nel secondo caso, invece, non distruggendo l'oggetto, lasciamo che sia il garbage collector a scaricare le risorse invocando il distruttore prima della finalizzazione. Ciò signfica che fino a un tempo imprecisato le nostre risorse rimarrano utilizzate . Codice C#: public void ReadMessage(string path){ Stream stream1 = null; StreamReader reader1 = null; stream1 = typeof(Person).Assembly.GetManifestResourceStream(path); reader1 = new StreamReader(stream1); Console.WriteLine(reader1.ReadLine());} Nel terzo caso invece vediamo un reference type object dichiarato come se fosse di un tipo valore. In realtà, questa è una semplice "illusione" propinataci dal compilatore. Il nostro oggetto è allocato sul managed heap, ma la semantica che esso assume, dal nostro punto di vista, è quella di un oggetto sullo stack. Questo ha un'importante implicazione: il compilatore genera automaticamente il codice per rilasciare le risorse usate dal nostro oggetto (ovviamente solo se necessario, ovvero se implementa IDisposable ), esattamente come il C++ nativo inserisce una chiamata ai distruttori delle variabili automatiche alla fine del metodo. Questo idioma, noto come deterministic finalization, è diventato in C++/CLI un nuovo idioma, analogo ma differente (a causa della diversa implementazione dell'operatore delete), detto deterministic cleanup . Codice C#: public void ReadMessage(string path){ Stream stream1 = null; StreamReader reader1 = null; stream1 = typeof(Person).Assembly.GetManifestResourceStream(path); StreamReader modopt(IsConst) local1 = (StreamReader modopt(IsConst)) new StreamReader(stream1); try { reader1 = local1; Console.WriteLine(reader1.ReadLine()); } fault { reader1.Dispose(); } reader1.Dispose();} * In C++/CLI una classe dichiarata con un distruttore, è mappata automaticamente in una classe che implementa IDisposable e il suo distruttore è mappato nel metodo Dispose. ** In C++/CLI è possibile dichiarare un finalizzatore . In questo modo, quando l'oggetto sta per essere distrutto non in maniera deterministica, bensì appena prima di una garbage collection è possibile svolgere un po' di custom behavior (per esempio tracciarlo)... oltre a invocare, com'è naturale, il distruttore affinchè vengano rilasciate le risorse. Questo è possibile perchè il compilatore genera in questo modo il metodo Dispose: protected virtual void Dispose([MarshalAs(UnmanagedType.U1)] bool flag1){ if (flag1) { this.~Person(); } else { try { this.!Person(); } finally { base.Finalize(); } }} Anzichè quello che avremmo in assenza di un finalizzatore : protected virtual void Dispose([MarshalAs(UnmanagedType.U1)] bool flag1){ if (flag1) { this.~Person(); } else { base.Finalize(); }} Vediamo quindi il seguente esempio: using namespace System;public ref class Person{private: String^ name_;public: Person (String^ name): name_ (name) { } ~Person () { Console::WriteLine (name_ + ": I'm releasing resources...!"); } !Person () { Console::WriteLine (name_ + ": I'm going to be finalized...!"); Console::WriteLine (name_ + ": I will call the destructor...!"); delete this; }};void DeterministicCleanupBehavior (){ Person person ("Guy on the heap with stack semantic");}void NonDeterministicCleanupBehavior (){ Person^ person = gcnew Person ("Guy on the heap");}int main(array<System::String ^> ^args){ Console::WriteLine ("Began!"); DeterministicCleanupBehavior (); NonDeterministicCleanupBehavior (); Console::WriteLine ("Ended!"); return 0;} Produrrà il seguente output: Began!Guy on the heap with stack semantic: I'm releasing resources...!Ended!Guy on the heap: I'm going to be finalized...!Guy on the heap: I will call the destructor...!Guy on the heap: I'm releasing resources...! In realtà non potremmo prevedere quando viene finalizzato dal garbage collector il nostro "guy on the heap"... ma essendo il programma molto breve è naturale che venga scaricato soltanto alla fine dell'esecuzione (è ovvio che se dopo la chiamata a NonDeterministicCleanupBehavior il nostro programma eseguisse una lunga serie di istruzioni sarebbe probabile che il "guy on the heap" venga finalizzato in un qualche istante prima della terminazione del processo).

Membership Provider for Firebird

Andrea Sansottera — Mon, 02 May 2005 12:33:00 GMT

Ispirato e istruito dalla sessione di Andrea, spero di poter iniziare questa settimana questo piccolo progetto. Si tratta innanzitutto di creare uno script per la creazione del database e poi codare il membership provider. Appena lo comincio apro un nuovo workspace su GotDotNet!

Enterprise Library for Firebird: moved

Andrea Sansottera — Mon, 02 May 2005 12:30:00 GMT

Ho deciso di spostare il progetto su GotDotNet. Pubblicherò lì news (con feeds RSS!), nuove releases, etc.. Ci sono anche un forum e un bug tracker, che naturalmente potete utilizzare. Ho già pubblicato le due "vecchie" releases (0.6 e 0.7.0) e i sorgenti sfruttando il sistema di source control (integrato tramite plugin in Visual Studio!). Ora vorrei creare un installer (in bundle con l'Enterprise Library e il provider ADO.NET per Firebird). Devo soltanto trovare il tempo di leggere le licenze e realizzarlo. Putroppo non sono ancora riuscito a fare una pagina di redirect sul vecchio sito perchè ho dimenticato la password... troverò un sistema per farlo (spero!). Nome workspace: Enterprise Library for Firebird Indirizzo: http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=1f216647-4011-40cd-8dc7-174eda97aad1

n-mila versioni di Visual Studio

Andrea Sansottera — Wed, 27 Apr 2005 10:31:00 GMT

Condividendo le opinioni di Andrea in merito all'inclusione nei soli prodotti Team System degli strumenti per lo unit testing, volevo ora portare il ragionamento un po' oltre. Per quale motivo tutte queste versioni di Visual Studio? Probabilmente ci avrete già pensato: perchè non rilasciare una piattaforma, che potremmo chiamare "Visual Studio Foundation", e poi tutti i plugin del caso, acquistabili separatamente e in ogni momento? Insomma un modello àla Eclipse o Netbeans... Immaginate di avvicinarvi alla programmazione in ambiente Windows. Ad oggi, probabilmente su consiglio di qualche amico, compreresti uno dei prodotti express, diciamo C# Express. Se non avete mai fatto unit testing, e un giorno decideste di imparare a farlo, molto difficilmente acquistereste i Team System, dopo una breve ricerca su Google troverete probabilmente NUnit. A un certo punto potrebbe nascere l'esigenza di sviluppare un'applicazione web... a quel punto tornereste dal rivenditore di fiducia e comprare Visual Web Developer... o magari la versione Professional. E se un giorno doveste iniziare a lavorare in un gruppo di 5 o 10 persone? Oppure se voleste semplicemente progettare un software e vorreste usare il class designer? Un nuovo acquisto probabilmente... E se invece bastasse una semplice puntatina sul nuovo scintillante "Visual Studio Extensibility Center" di Microsoft... un paio di click, il numero di carta di credito... qualche minuto di download... per avere immediatamente integrati nel vostro "Visual Studio Foundation" i plugin che soddisfano le vostre esigenze? Un plugin per C#, poi uno per le Windows forms, un altro per le web forms... poi quello per lo unit testing, magari un giorno potreste desiderare il class designer... o magari un collega potrebbe passarvi del codice VB, o C++... e allora scegliereste l'estensione oppurtuna per il vostro ambiente. Tutto questo andrebbe ad affiancarsi, naturalmente, ai numerosi plugin, già esistenti, di terze parti (ad esempio, quello per Eiffel).

Visual C++ 2005 and *.vcproj

Andrea Sansottera — Wed, 20 Apr 2005 12:37:00 GMT

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.

"What is Indigo?"

Andrea Sansottera — Mon, 11 Apr 2005 16:25:00 GMT

Un'ottima introduzione (e dimostrazione) da parte di uno dei software architect che lo hanno ideato: http://channel9.msdn.com/ShowPost.aspx?PostID=56397 42 minuti circa

NUnit... MBUnit o CSUnit?

Andrea Sansottera — Sun, 10 Apr 2005 00:10:00 GMT

Uso NUnit con discreta soddisfazione, ma mi chiedevo se qualcuno di voi abbia provato i due progetti open-source "concorrenti". Non ho molto tempo attualmente per provarli, qualcuno che li ha già usati sa darmi un parere?

Enterprise Library for Firebird 0.7.0

Andrea Sansottera — Tue, 05 Apr 2005 22:49:00 GMT

Ho effettuato qualche piccola modifica al pacchetto. Grazie ad Alessandro Petrelli per le sue correzioni sullo script sql per la creazione del database Northwind. Dal changelog: 5th April 2005 - version 0.7.0 released * License changed into LGPL * Cleaned up "bin" and "obj" directories from some files which were used during the initial development process * Minor changes to "NorthwindForFirebird.sql" (thanks to Alessandro Petrelli) * Minor changes to "Readme.txt" * Added "Changelog.txt" * Version changed into 0.7.0 La potete scaricare qui:http://digilander.libero.it/Syscall/Andrew.EnterpriseLibrary-20050405.zip Se riesco in questi giorni farò richiesta presso SourceForge.