Qualsiasi cosa tu abbia bisogno di calcolare, un computer può farlo. Basta conoscere l’algoritmo giusto e avere abbastanza tempo.

La leggerezza della conversazione e il mezzo litro di De Koninck ormai in dirittura di arrivo hanno persuaso il matematico che c’è in me dal contraddire questa affermazione a prima vista scontata.
Non è così facile da intuire, ma esistono problemi che un computer non può risolvere. Risposte che non possono essere calcolate.

Questo fatto, dimostrato da personalità come Alan Turing e Alonso Church nei primi decenni del Novecento, assieme al teorema di incompletezza di Gödel (che è, a ben vedere, una riformulazione dello stesso concetto), ha causato un terremoto nella matematica che, dagli anni ’30 in poi, non è stata più la stessa… Quello che più mi stupisce personalmente del risultato di Turing è la relativa facilità ed “eleganza” con cui sia possibile spiegarlo e comprenderlo, tanto che proverò a riassumerlo nelle poche righe di un articolo del mio blog.

Cominciamo mettendo in chiaro di cosa stiamo parlando. Cosa intendiamo per “risolvere un problema?”. Per noi ogni problema di calcolo è rappresentato da una funzione che per ogni valore in input assume un preciso valore di output. Risolvere il problema significa calcolare il valore della funzione a partire da un preciso input. Per fare ciò è necessario eseguire un algoritmo, ovvero una serie finita di istruzioni non ambigue che portano in un tempo finito al calcolo del risultato. La clausola “tempo finito” non è scontata. In effetti alcuni algoritmi, su alcuni input, possono non terminare mai, per esempio entrando in un ciclo infinito. In questo caso si dice che l’algoritmo diverge.

La prima cosa di cui dobbiamo renderci conto è che l’insieme di tutti gli infiniti possibili algoritmi è numerabile, ovvero ogni algoritmo è associabile biunivocamente ad un numero naturale. Dimostrare formalmente questo fatto è lungo e tedioso, ma possiamo rendercene conto pensando a come rappresentiamo nei calcolatori un algoritmo scritto in un qualche linguaggio di programmazione. Un file di testo contenente il codice sorgente dell’algoritmo cos’è se non un grosso numero naturale codificato in forma binaria?

Una volta capito ciò, un primo indizio del fatto che esistano problemi irrisolvibili, ovvero per i quali non esiste un algoritmo adatto, ci viene dalla teoria degli insiemi. Sappiamo infatti che l’insieme delle funzioni ha la cardinalità del continuo e quindi non è numerabile. In altre parole, non c’è una corrispondenza biunivoca tra problemi e algoritmi: i problemi possibili sono molti di più.
Questo però, non è un risultato facile da ottenere senza scrivere pagine e pagine su teoria degli insiemi e numeri cardinali, mentre io vi avevo promesso un ragionamento semplice e facilmente spiegabile. Inoltre, ragionare in questo modo non ci aiuta affatto a capire quali sono effettivamente i problemi che possiamo risolvere e quali no.

Per capire meglio la questione ci concentriamo ora su un problema specifico, il cosiddetto problema della fermata o Halting problem per gli amici anglosassoni. Si può formulare così: dato un algoritmo P e un input I, l’algoritmo termina con una risposta? Più precisamente vogliamo calcolare la seguente funzione:

Nota per i pignoli
Detta così non sembra una funzione . In realtà lo è, perché l’algoritmo P è, come abbiamo visto, codificabile da un numero naturale, e la coppia (P,I) è a sua volta codificabile da un numero naturale con la classica formula di Cantor , che fornisce una biezione tra numeri naturali e coppie di numeri naturali. Le risposte SI e NO ovviamente possono essere codificate con 1 e 0, 42 e 69, o qualsiasi cosa…
Fine della nota per i pignoli

Detto ciò, vediamo dove vogliamo arrivare. Vogliamo dimostrare che non esiste un algoritmo capace di calcolare la funzione H. Per farlo dovremmo fare un giro su noi stessi ottenendo una contraddizione. Se esistesse un tale algoritmo, allora potremmo scrivere un algoritmo con queste caratteristiche:

La funzione G, banale da implementare una volta ottenuto un algoritmo per H, restituisce NO se H riferisce che P(P) diverge, mentre diverge, ovvero entra in un ciclo infinito, in caso contrario. Quando scrivo P(P) intendo l’esecuzione dell’algoritmo P usando come input la codifica di se stesso.

Come si comportano le nostre due funzioni H e G messe assieme? Vediamo ad esempio cosa succede se valutiamo H(G,G). Che risposta possiamo ottenere? Entrambe sarebbero paradossali!

Infatti se ottenessimo SI, vorrebbe dire che G(G) termina, ma G(G) termina solo se H(G, G) risponde NO! Viceversa, se H(G, G) rispondesse NO vorrebbe dire che G(G) diverge. Ma G(G) diverge solo se H(G, G) risponde SI!

Ecco scovata la contraddizione. Guardando bene tutto il ragionamento ci accorgiamo che l’unica supposizione che abbiamo fatto è l’esistenza di un algoritmo per calcolare H, e abbiamo quindi dimostrato per assurdo che è impossibile.

Un problema non risolvibile come questo è detto indecidibile, e come questo ce ne sono infiniti altri. Il problema della fermata è stato il primo ad essere dimostrato tale da Turing, e riveste quindi una certa importanza storica, ma non solo. La dimostrazione di indecidibilità di moltissimi altri problemi si basa sulla riduzione di tali problemi all’halting problem. Se si dimostra che la soluzione di un problema risolverebbe anche l’halting problem, se ne deduce automaticamente che una tale soluzione non esiste.

In un certo senso è un bene che non abbia speso la serata in birreria a convincere i miei amici ingegneri di ciò che ho scritto in questo post. Una pagina web è senz’altro un posto migliore per questo genere di discorsi!

Per concludere in bellezza non posso non linkare questa geniale pagina, dove l’indecidibilità dell’halting problem è dimostrata… in quartine in rima!
Buona lettura

Dopo essermi divorato la maggior parte dei video disponibili, quindi, mi divertirò scrivendo la mia opinione sulle novità che ritengo più importanti.

LLVM vs The Rest Of The World

Apple investe fortemente nel progetto LLVM ormai da quattro anni, e i risultati si vedono. Xcode 4.2, che verrà rilasciato assieme ad iOS 5 questo autunno, includerà quello che Apple chiama “LLVM 3.0″, che aggiunge tra le altre cose un nuovo register allocator, e supporto per il type-based alias analysis. Apple ha incluso Clang come compilatore alternativo per i linguaggi C/C++ e Objective-C già da tempo, ma la novità è che per la prima volta GCC viene ufficialmente dichiarato deprecato sia su OS X che su iOS, e che Apple incoraggia gli sviluppatori a migrare al nuovo compilatore. Non mi stupirei se tra due anni, OS X 10.8 non includesse più alcuna versione di gcc.
Tra le novità di rilievo che verranno ufficialmente introdotte con Xcode 4.2, quella che mi sta più a cuore è il supporto al C++0x. Il supporto al nuovo standard non è ancora completo, ma le novità già implementate sono tra le più importanti, come gli r-value references e i vararg templates. Xcode 4.2 includerà anche libc++, la nuova implementazione della libreria standard del C++, del progetto LLVM. Oltre a supportare al 99% tutte le caratteristiche della libreria standard di C++98 e C++0x (manca solo <atomic>), i benefici in termini di performance di libc++ rispetto all’implementazione GNU sono sbalorditivi.

Objective-C Automatic Reference Counting

Questa novità è senza dubbio la più interessante, anche dal punto di vista tecnico. Objective-C ha sempre supportato un modello abbastanza particolare di gestione della memoria. La gestione è manuale, a carico del programmatore, ma al contrario del C++, ogni oggetto ha un reference count, ovvero un contatore che tiene traccia di quanti riferimenti attivi stanno puntando all’oggetto. Quando il conteggio va a zero, il runtime dealloca l’oggetto. Assicurarsi che questo conteggio resti coerente è compito del programmatore, ma le convenzioni adottate dalle librerie di sistema rendono questo compito relativamente semplice, e abbastanza meccanico. Ciononostante, la gestione automatica della memoria è la moda del ventunesimo secolo, per cui con OS X 10.5 Apple ha introdotto in Objective-C 2.0 il supporto al garbage collection. Il garbage collector implementato da Apple funziona molto bene ma porta con se due principali problemi:

1. Codice compilato con il garbage collector non è binary-compatible con codice compilato senza
2. Tutti gli svantaggi di un garbage collector: pause dovute all’esecuzione del collector, uso della memoria non deterministico, ecc…

Per quest’ultimo motivo, legato a performance ed uso della memoria, Apple non ha mai reso disponibile su iOS il garbage collector dell’Objective-C. Anche su OS X, l’uso del GC non è mai diventato molto popolare…

L’Automatic Reference Counting risolve il problema della gestione della memoria in modo totalmente diverso. Con ARC, il modello di gestione della memoria del linguaggio resta reference-counted, ma ora è il compilatore ad assicurarsi che il reference count venga mantenuto coerente, al posto del programmatore, seguendo automaticamente le convenzioni di ownership che prima venivano adottate manualmente dagli sviluppatori. Il risultato è una gestione totalmente automatica della memoria, senza gli inconvenienti di inefficienza e non determinismo di un garbage collector.

Una caratteristica interessante di ARC sono i cosiddetti zeroing weak pointers. Un weak pointer è un puntatore che non trattiene l’ownership dell’oggetto, ovvero non viene considerato nel conteggio dei riferimenti attivi. Un oggetto può quindi essere deallocato anche se ci sono dei weak pointers che lo puntano. I weak pointers sono assolutamente necessari in un sistema reference-counted, per evitare i cosiddetti ref-cycles, ovvero situazioni in cui due o più oggetti si puntano a vicenda in circolo, impedendo quindi ai singoli reference count di andare a zero. Un garbage collector si accorge di questa situazione eseguendo qualche algoritmo di rilevamento dei cicli, che è il task che porta via la maggior parte del tempo in tutti i normali garbage collector. In un sistema puramente refcounted, invece, questa situazione va gestita spezzando intenzionalmente il ciclo, tramite un weak pointer. Prima di ARC, spezzare il ciclo faceva parte dell’attività di gestione della memoria manuale affidata al programmatore, che doveva però anche preoccuparsi di non lasciare dangling pointers verso oggetti ormai defunti. Una proprietà importante dei weak pointer implementati da ARC è che diventano automaticamente nulli quando l’oggetto a cui puntano viene deallocato. Ciò evita in partenza numerosi tipi di bug.

I dettagli del funzionamento di ARC sono molto interessanti dal punto di vista dell’implementazione. Una documentazione particolarmente dettagliata del funzionamento e dei criteri di design è disponibile sul sito del progetto LLVM, a questo indirizzo: http://clang.llvm.org/docs/AutomaticReferenceCounting.html
Non è un caso che questa documentazione si trovi sul sito di LLVM. Apple ha infatti implementato questa nuova caratteristica del linguaggio solo su Clang, senza toccare gcc. E visto che gli ingegneri Apple hanno più volte raccomandato di migrare prima possibile dal modello di gestione manuale ad ARC, questo fatto segna ulteriormente il deprecamento di gcc su OS X e iOS, in favore di Clang.

App Sandboxing

L’application sandboxing è l’evoluzione e l’estensione a livello dell’intero sistema operativo di un meccanismo che si vede da un po’ di tempo su tutti i principali browser web. In Chrome, ad esempio, ogni tab viene gestita da un processo diverso. Lo scopo è quello di isolare eventuali bug a singole parti dell’applicazione. Su Lion, questo concetto è supportato direttamente dal sistema operativo che offre delle semplici API per la sua implementazione, e ci aggiunge vari meccanismi di sicurezza.

L’implementazione dell’App Sandboxing si snoda in due punti. La separazione dell’applicazione in parti separate che verranno eseguite in processi diversi, e la restrizione dei privilegi di ogni singola parte.
Le API fornite dal sistema per modularizzare l’applicazione sembrano a prima vista molto semplici. Si definiscono in Xcode i vari componenti, che verranno compilati in eseguibili diversi. Solitamente, in questo tipo di sistemi il problema maggiore è la comunicazione tra i processi. Le nuove API si concentrano sulla richiesta di dati o servizi dai vari componenti, non sull’esecuzione e la comunicazione con dei processi. A seconda del servizio richiesto dall’applicazione principale (ad esempio “parsing di un file PDF”), il sistema si preoccupa di eseguire il componente giusto, e mettere le due parti in comunicazione, tramite un’API di scambio di oggetti ad alto livello, chiamato XPC. Assieme a questo meccanismo di scambio messaggi è stata aggiunta anche un’API chiamata IOSurface, basata su memoria condivisa, per la condivisione tra le varie componenti di grosse quantità di dati, buffer audio/video, ecc..

La seconda fase consiste nel definire i privilegi dei singoli moduli dell’applicazione. L’intenzione è quella di negare tutte le operazioni di cui un modulo non ha bisogno, in modo da limitare al minimo i danni causati da una falla di sicurezza di un componente. Se per esempio l’apertura e la decodifica di un file sono implementate in un modulo, questo avrà solo il permesso di leggere il filesystem, ma non di accedere alla rete. Se il contenuto del file va trasmesso via rete in qualche modo, il modulo che si occupa della trasmissione avrà il permesso di collegarsi ad un server remoto, ma non di accedere ai file. L’accesso al filesystem, in particolare, è gestito a mio avviso molto bene. Si può scegliere ad esempio, che un modulo o l’intera applicazione non abbia il permesso di accedere al filesystem se non in una particolare directory riservata ai dati dell’applicazione (dentro a qualche sottodirectory della home, di solito). Ma se si tratta, ad esempio, di una applicazione che tratta documenti dell’utente, l’accesso al filesystem va consentito per permettergli di aprire i propri documenti. Per casi come questo, le librerie di sistema fanno semplicemente il loro lavoro. Le finestre di dialogo per scegliere che file aprire o salvare, ad esempio, restituiscono un ticket che permette all’applicazione di aprire il file scelto dall’utente, ma nient’altro. Oltre all’accesso al filesystem e alla rete, è possibile decidere anche disciplinare l’accesso a dispositivi esterni, volumi rimovibili, stampanti, scanner, ecc…

Questi vincoli vengono forzati dall’OS, e se un’applicazione non li rispetta viene terminata. I vincoli del sandboxing sono specificati nel Property List dell’applicazione, per cui per far si che il meccanismo funzioni è necessario che l’applicazione sia firmata digitalmente dall’autore. La firma garantisce che l’applicazione non sia stata modificata, e quindi che i vincoli specificati dall’autore non siano stati successivamente alleggeriti. Il meccanismo si integra anche bene con il Mac App Store, che di default fornisce sempre applicazioni firmate. Sull’App Store per Lion, il Sandboxing è obbligatorio per tutte le applicazioni pubblicate sullo store, che devono per lo meno specificare i vincoli dell’applicazione principale, anche senza separare alcun modulo. La conseguenza di ciò, è che se un utente scarica dall’App Store un’applicazione di cui è scritto che “non accede alla rete” o che “non accede al filesystem”, può essere sicuro che si tratta della verità.

Nonostante il possibile overhead introdotto dalla comunicazione, sembra essere un meccanismo molto efficiente. Ad esempio, sembra che QuickTime sia stato riscritto con questo meccanismo in modo che il componente che decodifica i dati sia diverso dal componente che li visualizza a schermo. L’uso del sandboxing sembra sia stato adottato pesantemente all’interno del sistema stesso. Anche Anteprima, ad esempio, separa i componenti per la lettura e la decodifica dei file che legge, il che significa che possiamo dimenticarci quelle falle alla Acrobat che sfruttano PDF malformati per fare danni al sistema.

Tutto il resto

Di altre novità interessanti ce ne sono parecchie. Sono presenti, ovviamente, tutte le API necessarie per integrare le applicazioni con le nuove funzionalità di Lion, come Versions, Resume, e Mission Control, e l’accesso ad iCloud. C’è un nuovo framework per la crittografia. iOS 5 include GLKit, che rende molto più semplice la gestione di OpenGL ES 2.0. Su Lion, le novità di Cocoa includono un nuovo meccanismo di autolayout dei widget, e meccanismi di resolution independence simili a quelli usati nel passaggio al retina display dell’iPhone 4.

Alla fine sembra che le novità per gli sviluppatori siano interessanti quanto (e forse di più) di quelle per gli utenti finali. Bisogna solo aspettare di vedere come tutto ciò si comporta su strada. La notizia di oggi è che Lion è stato distribuito in Golden Master agli sviluppatori registrati al Developer Program, quindi basterà aspettare solo ancora un po’.

Chi ha programmato almeno una volta in stile funzionale sa cosa sono le lambda expression: delle espressioni con le quali è possibile definire in loco il corpo di una funzione anonima. In C++ 2011 la sintassi per definire una lambda expression è la seguente:

[capture-list](arguments) -> return_type {body}

Ed ecco un esempio concreto, che usa std::sort per ordinare un vettore in base al modulo degli elementi.

void f()
{
   std::vector<int> v;
   // fill the vector...
   std::sort(v.begin(), v.end(), [](int a, int b) {
      return abs(a) < abs(b);
   });
}

La coppia di parentesi quadre viene chiamata lambda introducer, ed indica l’inizio di una lambda expression. Dopo il lambda introducer si specifica la lista degli argomenti accettati dalla lambda con la solita sintassi tra parentesi tonde. In questo esempio, la lambda che ho scritto non specifica il valore di ritorno, perchè nel caso in cui il corpo contenga una singola istruzione di return, il tipo può essere automaticamente dedotto dal compilatore (in questo caso bool).

Il corpo di una lambda può riferirsi a variabili presenti nello scope che la racchiude. In questo caso, all’interno delle parentesi quadre si può specificare una lista di variabili che verranno catturate dalla lambda. Si può decidere di catturare le variabili per valore o per riferimento. Nel primo caso il valore viene copiato e la lambda ottiene una propria copia della variabile. Nel secondo caso la lambda cattura un reference alla variabile, che può quindi anche essere modificata. Un esempio:

void f(int threshold)
{
   std::vector<int> v;
   int comparisons = 0;
   // fill the vector ...
   std::sort(v.begin(), v.end(),
             [=threshold, &comparisons] (int a, int b) -> bool {
                comparisons++;
                return abs(a) < abs(b) - threshold;
             });
   std::cout << "Array ordinato con " << comparisons << " confronti\n";
}

Com’è facile intuire, il simbolo ‘=’ indica la cattura per valore mentre ‘&’ quella per riferimento.
Non è necessario specificare l’intera lista delle variabili catturate. Specificando solo un singolo ‘=’ o un singolo ‘&’, si decide la modalità di cattura di default, dopodichè il compilatore si arrangerà a catturare tutte le variabili necessarie.

Chi è abituato a programmare in linguaggi funzionali, dove le funzioni sono un entità di prima classe, si starà chiedendo “un’espressione lambda che tipo ha?”.
Rispondere a questa domanda richiede un approfondimento su come sono implementate sotto il cofano. In pratica il discorso è molto semplice, e prevede teoricamente ‘solo’ una riscrittura del codice. Il codice dell’ultimo esempio viene trattato dal compilatore come se fosse riscritto così:

class __fresh_class_name {
   int threshold;
   int &comparisons;
public:
   __fresh_class_name(int t, int &c) : threshold(t), comparisons(c) {}
   bool operator()(int a, int b) const {
      comparisons++;
      return abs(a) < abs(b) - threshold;
   }
};
 
void f(int threshold)
{
   std::vector<int> v;
   int comparisons = 0;
   // fill the vector ...
   std::sort(v.begin(), v.end(), __fresh_class_name(threshold, comparisons));
}

In pratica quindi, una lambda expression crea un’istanza di un function object, il cui tipo viene implicitamente dichiarato dal compilatore. Le variabili catturate sono memorizzate in variabili membro del function object, mentre il corpo finisce nell’overload dell’operator(). Questo approccio ha un vantaggio principale: la totale assenza di qualunque overhead a runtime. Anzi, molto spesso le lambda più semplici possono essere compilate inline generando codice molto efficente.

Il tipo generato dal compilatore per la dichiarazione di una singola lambda expression non è esplicitamente menzionabile nel codice. Oltretutto, diversamente da quello che accade in altri linguaggi, il tipo delle lambda non ha a che fare con il tipo dei parametri e con il tipo di ritorno, ma è specifico e univoco per ogni singola lambda expression.
In altre parole, due lambda con gli stessi parametri e lo stesso tipo di ritorno non hanno lo stesso tipo.
Tuttavia, volendo assegnare una lambda ad una variabile è possibile far dedurre automaticamente il tipo al compilatore con la parola chiave ‘auto’, il cui comportamento è un’altra novità del nuovo standard. Esempio:

void f() {
   auto square = [](int a) { return a * a; };  
   std::cout << square(4) << std::endl;
}

Per passare una lambda come parametro di una funzione invece, come nel caso dell’std::sort usata prima, l’assenza di un tipo ben definito non è un problema. Il codice è esattamente lo stesso di una funzione che si aspetta un function object. Il prototipo di std::sort ad esempio, non è cambiato rispetto al C++03, ed è il seguente (paragrafo 25.4.1.1 del documento ISO):

template<class RandomAccessIterator, class Compare>
void sort(RandomAccessIterator first, RandomAccessIterator last, Compare comp);

In altri casi è difficile gestire le cose con questo meccanismo. Alcune volte ad esempio potremmo non voler implementare una funzione template. In questi casi torna molto utile una novità introdotta nella libreria standard, ovvero la classe std::function, dichiarata dall’header <functional>, che si comporta come un ‘wrapper’ per oggetti ‘invocabili’ con un certo prototipo, siano essi puntatori a funzione, function objects o lambda expression:

void f() {
   std::function<int(int)> square = [](int a) { return a * a; };
   std::cout << square(4) << std::endl;

L’implementazione di std::function è di per se molto semplice e sfrutta i vararg templates per poter funzionare qualsiasi sia il numero di parametri specificato.

Si chiude qua la mia (quasi) breve panoramica su questa funzionalità, che a mio avviso è una delle più interessanti del nuovo standard. Per poter provare su strada queste non tutti i compilatori sono adatti. Per ora le lambda sono supportate da GCC 4.5 e da Visual C++ 10, mentre non sono ancora implementate in Clang (non ho notizie riguardo ad altri compilatori).

Nonostante lo standard internazionale attuale risalga al 1998 (con qualche correzione nel 2003), il linguaggio ha visto un notevole sviluppo negli ultimi anni, grazie principalmente all’evoluzione dei vari compilatori presenti sul mercato, che oltre ad essere ormai completi e per la maggior parte aderenti allo standard, sono anche più performanti di quanto non si potesse sognare qualche anno fa (vedi ad esempio Clang). Il nuovo standard poggia su queste fondamenta e cerca di “modernizzare” il linguaggio, aggiungendo alcune feature veramente interessanti che, pur essendo a prima vista delle modifiche minori, rendono il C++ un linguaggio in alcuni sensi molto diverso.

La buona notizia è che, a differenza dello standard del 1998, i vari produttori di compilatori sembrano intenzionati a fare le cose per bene fin da subito. Il compilatore g++ di GNU, che è praticamente lo standard de facto su tutte le piattaforme diverse da Microsoft Windows, implementa già buona parte delle nuove caratteristiche del linguaggio, mentre Visual C++ 10 di Microsoft ne ha introdotto alcune tra le più interessanti.

In questo post cercherò di illustrare la novità più importante dal punto di vista delle performance del C++, ovvero l’introduzione dei cosiddetti r-value references.

Il problema

Il comitato di standardizzazione, nello scegliere le funzionalità da aggiungere al linguaggio, ha pensato a come risolvere i principali problemi incontrati dagli utenti del linguaggio attuale. Gli r-value references risolvono un problema molto sentito nella classica programmazione C++: le copie ridondanti di oggetti.

Il C++ è l’unico linguaggio object-oriented attualmente utilizzato in cui gli oggetti hanno una copy semantics. Gli oggetti automatici (quelli allocati sullo stack per capirci), quando vengono passati come parametri o restituiti da una funzione vengono copiati. Il chiaro vantaggio è la coerenza del comportamento degli oggetti rispetto ai tipi base.

Tutti i programmatori C++ sanno come gestire questa caratteristica in modo da evitare prestazioni penose: si passano gli argomenti per riferimento, o si usano soluzioni più sofisticate come l’implicit-sharing con copy-on-write (vedi i container di Qt). Per quanto ci si possa impegnare, però, rimarrà sempre un overhead dovuto a copie superflue.

Vediamo ad esempio la classica implementazione di una funzione swap:

template <typename T>
void swap(T &a, T &b)
{
   T tmp = a;
   a = b;
   b = tmp;
}

Passare i parametri per riferimento in questo caso non evita la copia dell’oggetto a nell’oggetto temporaneo tmp. Allo stesso modo, dopo la seconda istruzione ci saranno due copie dell’oggetto b. Queste copie sono inutili perchè noi non volevamo copiare niente, ma spostare il contenuto di un’oggetto nell’altro e viceversa. Con gli r-value references e una piccola funzione ausiliaria della libreria standard, la funzione swap in C++0x può essere scritta come segue:

template <typename T>
void swap(T &a, T &b)
{
   T tmp = std::move(a);
   a = std::move(b);
   b = std::move(tmp);
}

La funzione std::move() abilita la move semantics del proprio argomento, consentendoci di spostare, invece che copiare, il contenuto di a in tmp, spostare b in a, e poi spostare nuovamente tmp in b, senza eseguire alcuna copia inutile.

Il trucco non sta nel corpo della funzione std::move(), che come vedremo è una funzione veramente semplicissima. Il trucco sta nell’introduzione di un nuovo tipo di reference, detto r-value reference, che nelle prossime sezioni cercherò di spiegare in modo relativamente comprensibile.

r-values e l-values

Prima di vedere in dettaglio il funzionamento di questa nuova caratteristica è bene fare un po’ di chiarezza su un concetto chiave della grammatica del C++: r-values vs l-values. Ogni espressione, quando viene valutata produce un valore. Ogni valore, in C++ come in tutti gli altri linguaggi imperativi, può essere un l-value, o un r-value (o entrambi).

Un l-value (che sta per left-value) è un valore che può stare a sinistra dell’operatore di assegnamento. Un r-value (che sta per right-value) è un valore che può stare solo a destra. È chiaro che un l-value è anche un r-value. In pratica tutto ciò che ha una precisa posizione in memoria ed è identificabile con un nome è un l-value. Ad esempio, i valori delle seguenti espressioni sono l-value:

n     // valore di una variabile
*p    // valore puntato da un puntatore
v[0]  // valore di un elemento di un'array

Mentre i seguenti sono r-value:

4          // una costante
func()     // il valore di ritorno di un metodo (se non ritorna un reference)
func() + 4 // un'espressione qualunque (se non ricade tra gli l-value)

È facile capire come mai non possiamo assegnare un valore ad una costante o all’oggetto temporaneo restituito da una funzione. La differenza tra l-values e r-values però non si nota solo in presenza di assegnamenti.
Prendiamo una funzione qualsiasi:

void func(int a, int &b, int const& c)
{
// ...
}

Cosa possiamo passare come parametri di questa funzione? Il primo parametro viene passato per valore e quindi copiato. Possiamo ovviamente passare di tutto ad un parametro passato per valore, sia r-value che l-value, senza problemi.

Il secondo parametro è invece passato per riferimento, e potrebbe quindi essere modificato dal corpo della funzione. Per questo motivo, ai parametri by reference è possibile passare solo degli l-value, e quindi non è possibile passare, ad esempio, un’espressione come 4 + 5 ad un parametro di questo tipo. In altre parole, i reference si associano (bind in inglese) solo ad l-values. È bene notare a questo punto che tra gli r-values ricadono anche tutti gli oggetti temporanei che risultano dalla valutazione delle espressioni. Vietare di modificare un oggetto temporaneo è un buon modo di evitare una serie spiacevole di subdoli bug.

Il terzo parametro è passato per riferimento costante. Cosa si può passare ad un parametro di questo tipo? Di nuovo, la risposta è “qualsiasi cosa”. In questo caso infatti, non c’è nessun pericolo a passare un r-value, perchè il parametro non verrà comunque modificato, e possiamo quindi passare un valore temporaneo senza problemi.

Abbiamo visto quindi che i classici reference si associano solo ad l-value, mentre i const-reference si associano sia ad l-value che r-value. Gli r-value reference, introdotti in C++0x, sono un tipo di reference non costante che può associarsi solo ad un r-value. Dove un classico reference si indicava con il simbolo &, gli r-value reference si indicano con &&. In altre parole:

int   a     = 0;
int&  lref  = a;   // Ok. l-value reference associato ad un l-value.
int&& rref  = a;   // Errore! r-value reference associato ad un l-value.
int&  lref2 = 5;   // Errore! l-value reference associato ad un r-value.
int&& rref2 = 5;   // Ok. r-value reference associato ad un r-value.

La domanda è: perchè vorremmo poter fare tutto ciò? Non abbiamo appena detto che modificare oggetti temporanei può essere pericoloso? In effetti, l’oggetto temporaneo creato nell’ultima riga viene distrutto subito, e quindi usando il reference rref2 si incorre sicuramente in un crash.
In realtà, combinando l-value ed r-value reference, si può implementare la move semantics di cui parlavamo sopra, permettendo di evitare moltissime copie semanticamente inutili.

Move semantics

Il trucco sta in come vengono risolte le chiamate in presenza di overloading di metodi. Prendiamo le seguenti due funzioni:

void func(int &i) { ... }
void func(int &&i) { ... }

Questo overloading è perfettamente valido e viene risolto con la seguente regola. Se alla funzione viene passato un l-value, viene chiamata la versione che prende il parametro con l-value reference. Se viene passato un r-value, la prima forma non può essere utilizzata e quindi si usa quella che prende il parametro con r-value reference, quindi:

int a = 0;
func(a);   // chiama func(int &)
func(5);   // chiama func(int &&)

Detto ciò entriamo finalmente nel vivo del discorso. Consideriamo una classe string, dichiarata in linea di massima così:

class string
{
   char *data;
public:
   string();
   string(char *data);

   string(string const& s) // copy constructor
   {
      copy(data, s.data);
   }

   string(string &&s) // move constructor
   {
      data = s.data;
      s.data = 0;
   }

   string operator=(string const& s); // copy assignment
   string operator=(string && s); // move assignment
};

Fino al costruttore di copie non c’è nulla di nuovo. La novità arriva nel costruttore che ho commentato come “move constructor”. Questo costruttore viene chiamato quando l’argomento è un r-value, e come si può vedere dal codice l’effetto è di spostare i dati dal parametro, lasciandolo essenzialmente vuoto, evitando il costo dell’operazione di copia. Questo si può fare senza problemi perchè sappiamo che l’argomento è un oggetto temporaneo e quindi nessuno andrà più ad utilizzarlo. Lo stesso discorso vale per gli operatori di “copy assignment”, che è il classico operatore di assegnamento, e di “move assignment”, che invece sposta i dati dal parametro senza il costo di una copia.

Ora abbiamo quindi la possibilità di capire il funzionamento e l’utilità della funzione std::move() che accennavo prima. La sua definizione è (a meno di dettagli) la seguente:

template <typename T>
T&& move(T&& a)
{
    return a;
}

In pratica std::move() non fa altro che prendere un parametro di qualsiasi tipo e ritornarlo come r-value, senza causare nessuna copia (al contrario di un ritorno per valore che avrebbe sempre prodotto un r-value ma causando una copia).
Nella versione di swap() definita prima quindi, è ora chiaro cosa accade. Il valore di std::move(a) è un r-value che viene passato al move constructor del tipo T (se esiste). Lo stesso discorso vale per i due assegnamenti successivi che andranno ad usare l’operatore di move assignment. In questo modo si eliminano tutte le copie inutili. Se il tipo in questione non supporta alcuna move semantics viene chiamato comunque il copy constructor e tutto continua a funzionare come prima.

Questo tipo di vantaggi non si applicano ovviamente solo a swap, ma a tutti quei casi in cui la copia è inutile, come ad esempio questo pezzo di codice:

std::string s1 = "ciao ", s2 = "come ", s3 = "va?";
std::string r = s1 + s2 + s3;

In un’espressione del genere abbiamo molte copie inutili. Prima viene copiato s1 nell’oggetto temporaneo che sarà il risultato di s1 + s2, per poi appendere il contenuto di s2. Fatto ciò, questo oggetto temporaneo viene copiato nell’oggetto temporaneo che sarà il risultato generale, che poi verrà copiato di nuovo dentro ad r. Ogni copia ha un costo proporzionale alla lunghezza della stringa copiata, e richiede un’allocazione di memoria dinamica. Utilizzando opportunamente la move semantics è possibile implementare un operator+(std::string &&s), che sposta i dati dei vari risultati intermedi invece di copiarli, richiedendo a tutti gli effetti una sola copia.

Utilizzando la move semantics, le prestazioni della maggior parte dei container e degli algoritmi standard aumenta drasticamente. Ad esempio, quando l’algoritmo sort() deve scambiare gli elementi di un vettore per ordinarlo, usando std::swap() sposta gli elementi invece di copiarli.
Stesso discorso per tutti quei casi in cui un container deve spostare elementi durante la riallocazione della memoria.

Gli r-value reference sono una feature rivolta principalmente agli autori di librerie e componenti riutilizzabili.
La cosa da notare è che il drastico aumento di performance che deriva da questa nuova funzionalità non richiede modifiche del codice che utilizza le nuove librerie. Alla fine, molto codice che usa la libreria standard o altre librerie che verranno portate al C++0x, potrà godere di un incremento di performance anche solo venendo ricompilato.

Perfect forwarding

Un altro problema risolto dagli r-value references ha a che fare con la programmazione generica.
Supponiamo per esempio di voler scrivere una funzione factory che alloca oggetti di un certo tipo e li ritorna all’interno di uno smart pointer come ad esempio shared_ptr (che da Boost ora è incluso anche nel nuovo standard).
In C++ classico potremmo scriverla così:

template <typename T, typename U>
std::shared_ptr<T>
factory(const U& arg)
{
    return std::shared_ptr<T>(new T(arg));
}

Questa funzione è molto semplice e non fa altro che restituire lo shared_ptr costruito con un oggetto di tipo T allocato per l’occasione. Idealmente vorremmo poter usare questa funzione in tutti i posti in cui useremmo l’espressione new T(…). In realtà però non è sempre possibile.
Ad esempio, cosa succede se il costruttore di A prende un parametro passato per riferimento non costante? Otteniamo un errore di compilazione nel punto in cui la funzione factory cerca di passare un const-reference ad un reference non costante.
Per risolvere il problema si potrebbe pensare di togliere il qualificatore const dal parametro di factory. In questo caso il codice funzionerebbe anche con parametri reference, ma sarebbe impossibile scrivere codice di questo tipo:

shared_ptr<A> ptr = factory<A>(5);

In questo caso, infatti la costante 5 non potrebbe essere passata by reference alla funzione factory.

Da questo esempio si vede che attualmente è impossibile creare una funzione generica che ripassi i propri argomenti ad un’altra funzione preservando esattamente lo stesso tipo con cui li riceve. Questo problema è noto come “perfect forwarding”. Con gli r-value references si risolve in modo molto semplice:

template <typename T, typename U>
std::shared_ptr<T>
factory(U&& arg)
{
   return std::shared_ptr<T>(new T(std::forward<U>(arg)));
}

La funzione std::forward() usata qui ha praticamente la stessa definizione di std::move(), ma grazie al nome diverso esprime chiaramente il suo intento, ovvero restituire direttamente il proprio argomento preservandone esattamente il tipo, compresa la sua natura di l-value o r-value. Così facendo, anche la chiamata factory<A>(5) sarà legale e la funzione factory funzionerà come voluto.

Conclusioni

Gli r-value references sono una delle feature di C++0x più difficili da capire ed utilizzare correttamente. Sono rivolti agli autori di librerie e componenti riutilizzabili, ma avvantaggiano la totalità degli utenti in modo trasparente.
Come per i vararg templates (template con lista di argomenti di lunghezza variabile), l’aggiunta di questa feature aumenta le performance e la generalità delle librerie C++ mantenendo leggibile e di alto livello il codice che le usa.
Volendo provare a sperimentare, i compilatori che già supportano questa novità sono G++ dalla 4.3 in poi, Microsoft Visual C++ dalla versione 10, e il branch di sviluppo di Clang ormai da parecchi mesi.
Ho cercato di spiegare l’argomento nel modo più comprensibile possibile. Qualsiasi commento a riguardo è benvenuto.

È per questo motivo che la comunità scientifica non può ancora accettare come prova l’enorme quantità di evidenze sperimentali a favore dell’ipotesi di Riemann, uno dei più importanti quesiti aperti della matematica moderna.

Di cosa parla questa ipotesi, e perchè è così importante? Partendo dall’antica grecia, Marcus du Sautoy lo spiega ai “profani” ripercorrendo la vita e le vicissitudini dei più importanti matematici che nei secoli si sono cimentati con i misteri nascosti nella sequenza dei numeri primi. Come sono legati tra loro? C’è qualche regolarità nella sequenza, o sono distribuiti a caso? Quanti primi si trovano in un certo intervallo? È possibile, dato un numero primo, trovare velocemente il successivo?

L’ipotesi di Riemann è l’ultima di questa serie di domande, rimasta irrisolta ormai per più di un secolo e mezzo dopo che Riemann l’ha accennata in un articolo del 1859 dove sosteneva di avere in cantiere una dimostrazione, andata poi persa a causa di una domestica troppo diligente.

Nonostante l’argomento possa spaventare, in realtà “L’enigma dei numeri primi” è un libro sorprendentemente leggero e scorrevole, in cui l’autore dimostra una grande capacità divulgativa spiegando il significato di concetti matematici molto complessi con metafore semplici e naturali.

Per concludere, non posso non consigliare la lettura de “L’enigma dei numeri primi” , a chiunque sia anche minimamente interessato all’argomento.

In poche parole, dopo essere stata per quasi 10 anni leader incontrastata del mercato dei telefoni cellulari, negli ultimi due anni Nokia non si è trovata preparata al nascere improvviso di agguerriti concorrenti.

Da un lato c’è Apple, che in tre anni con il suo iPhone ha rivoluzionato il mercato e monopolizzato il segmento degli smartphone high-end, attirando centinaia di migliaia di sviluppatori e centinaia di milioni di utenti.

Dall’altra parte c’è il sistema operativo Android di Google, assieme a tutti i produttori che l’anno adottato per i propri prodotti. Android ha avuto uno sviluppo rapidissimo negli ultimi due anni, e ora cominciano ad apparire proposte veramente interessanti nel comparto high-end, ma soprattutto continua a dilagare l’offerta nel segmento medio basso del mercato, con telefoni Android sotto i 100$.

Tra questi due giganti, Nokia si è trovata improvvisamente in inferiorità sia tecnica che commerciale. Il successo degli ultimi prodotti, nonostante la critica positiva, non è stato esaltante, e Symbian continua a non convincere ne gli sviluppatori, ne gli utenti. Relegato in una nicchia c’è MeeGo, eterna promessa che forse, se dio vuole, vedrà la luce su un vero dispositivo commerciale durante il 2011, ma di cui non si è ben capito il futuro.

La decisione di affidarsi al sistema operativo di Microsoft sembra azzeccata. Nonostante Microsoft non stia simpatica a nessuno, devo ammettere che Windows Phone 7 è un sistema molto interessante, che presenta alcuni elementi originali, una grande facilità d’uso, e strumenti di sviluppo veramente ottimi. D’altra parte, Microsoft non è un produttore di telefoni, e deve farsi strada tra i produttori per affermare il proprio sistema, cosa non facilissima vista l’agguerrita concorrenza di Android. L’accordo annunciato oggi permetterà di unire l’ecosistema software di Microsoft con l’esperienza di Nokia riguardo alla produzione di telefoni.

Leggendo bene quanto annunciato si vede che l’accordo va anche oltre, mettendo in gioco anche l’integrazione tra Bing e i servizi di mappe di Nokia, Xbox Live e l’Ovi Store ecc… In pratica, Nokia e Microsoft vogliono fondere i propri ecosistemi per dare vita ad un polo che attiri non solo utenti, ma anche sviluppatori. Per ora sembra una mossa vincente.

C’è una nota dolente in tutto ciò, non per Nokia, ma per chi contava di sviluppare sui prodotti Nokia. Nel 2008 Nokia acquistò Trolltech con lo scopo di fare di Qt il centro della propria strategia mobile. Di conseguenza, l’integrazione tra Qt e Symbian è cresciuta e Qt è diventato praticamente la piattaforma di sviluppo principale sui prodotti Symbian, soprattutto di fascia alta. Sembra quindi chiaro che il futuro di Qt nel mobile è legato a doppio filo a quello di Symbian.

La press-release di Nokia pubblicata oggi recita “Microsoft development tools would be used to create applications to run on Nokia Windows Phones, allowing developers to easily leverage the ecosystem’s global reach”. Questa frase non lascia molte speranze sull’eventualità di un porting di Qt per WP7.

Il team della divisione Qt Software di Nokia si è subito affrettato a chiarire il futuro di Qt dopo questo annuncio, assicurando che Qt non morirà e Nokia continuerà ad investirci attivamente. Ma quanto detto non mi convince, dal punto di vista di uno sviluppatore. A prescindere dalla qualità attuale del framework, sicuramente molto alta, la domanda veramente importante è: investire su Qt ora, è conveniente in un quadro a lungo termine?

Lo slogan di Qt è sempre stato “code once, run everywhere”. Quando si parla di sviluppo desktop questo slogan è sicuramente azzeccato, ma in campo mobile non si può dire altrettanto. Dall’annuncio di oggi, è chiaro che nel futuro prossimo le tre principali piattaforme del mercato saranno iOS, Android, e Windows Phone. Su iOS e Windows Phone l’uso di Qt è impossibile a prescindere. Su Android, è in corso un porting sperimentale, basato su Lighthouse, una tecnologia a sua volta sperimentale che non vedrà la luce prima di Qt 4.8, non prima di fine 2011. L’unica piattaforma mobile su cui Qt è realmente utilizzabile è Symbian, che sembra proprio destinata a morire. Come un lettore del blog di Qt Software ha sapientemente commentato, lo slogan rischia di diventare “code once, run nowhere”.

Che fine farà quindi Qt in ambito mobile? Personalmente vedo il suo futuro molto grigio, e se avessi investito tempo, denaro e know-how nello sviluppo di applicazioni mobile in Qt avrei veramente molto di cui lamentarmi…

Trovate tutte le informazioni necessarie nella sezione apposita del sito. Spero vivamente che questo documento torni utile al maggior numero possibile di persone e invito chiunque a collaborare.

“Hello world” è ciò che di solito si fa scrivere ai semplicissimi programmi di esempio mostrati a chi sta imparando le basi di un nuovo linguaggio di programmazione, come se quel piccolo programma fosse contento di essere stato scritto ed eseguito almeno una volta. Quale titolo migliore quindi per il primo post del neo-nato blog di un programmatore che ama programmare?

Personalmente torno online per la seconda volta, dopo quasi un anno di silenzio a seguito della completa cancellazione del mio blog precedente, causata da una spaventosa negligenza di Tophost sulla quale non mi dilungherò.

L’intenzione è rimasta la stessa: mettere ordine a tutte le idee e le nozioni che nel tempo si accumulano nella testa di uno studente universitario di Informatica e fare in modo, con un po’ di fortuna, che siano utili anche a qualcun altro.

Il primo vero post verrà alla luce probabilmente a Febbraio, dopo il mio esame di Calcolo Scientifico di cui sicuramente sentirete molto parlare in futuro su queste pagine. Nel frattempo, ho ripubblicato gli appunti del corso di Matematica Discreta di due anni fa. Per saperne di più andate su questa pagina.

Colgo l’occasione per ringraziare il mio amico Carmelo San Giovanni della NetMDM, che mi offre i suoi professionali servizi di hosting, e vi rimando al prossimo post.

Hello, World!