Il programmatore pigro

Ciao a tutti, Dopo qualche anno di inattività ho deciso di riprendere quanto avevo iniziato in questo blog ma in un nuovo sito completamente rinnovato.

https://codicepragmatico.it/

Ho esportato tutti gli articoli in modo che possiate ritrovarli in una nuova veste.

Questo articolo lo trovate nel nuovo sito https://codicepragmatico.it/

---> Principi di buona programmazione

Questi principi seguono quanto indicato nell'ottimo libro Head First Design Patterns (ISBN-13: 978-0596007126).

1. Separa le parti che cambiano da quelle che rimangono costanti

Durante il design di un'applicazione, è necesaario essere in grado di individuare le parti del codice che variano (o potrebbero variare in futuro) ed incapsularle in modo che siano indipendenti da quelle che tendono a rimanere costanti.

In questo modo, quando devo effettuare una modifica a tali parti, queste modifiche saranno molto più semplici e dovrò andare a modificare solo il codice che effettivamente cambia.

2. Scegli la composizione invece dell'ereditarietà

Questa regola si può riassumere come: HAS-A è meglio di IS-A. Quando collego due classi insieme, inserendo una come attributo dell'altra sto operando una composizione (HAS-A).

Tipicamente fare in modo che un oggetto abbia una caratteristica esterna ad esso è meglio di creare è un oggetto intrinsicamente possiede tale caratteristica.

L'esempio più semplice è la classe animale. Il comportamento dell'animale può sia essere scritto come metodo della classe ma è una pratica di buona programmazione fare sì che il comportamento sia un insieme di oggetti esterni all'animale ma che viene posto in composizione con questo ultimo.

Questo ha il vantaggio, oltre di rendere il codice più manutenibile, che posso cambiare il comportamento a runtime, rendono così il codice estremamente flessibile.

3.Programma ad interfacce, non a implementazioni

In questo caso il concetto di interfaccia non significa solo l'Interface di Java o C#, ma significa utilizzare il polimorfismo utilizzando superclassi (astratte o interfacce) al posto di classi concrete. Vediamo un esempio: Il seguente codice segue la programmazione per implementazione:

Dog d = new Dog(); d.bark();

Come si può notare questo codice è estremamente debole, in quanto se voglio cambiare animale dovrei cambiare entrambe le righe, e devo cambiarne una invece se voglio cambiare il verso.

Questo perchè aver dichiarato d come Dog ci obbliga ad utilizzare solo i metodi della classe concreta.

Il codice seguente invece segue la programmazione a interfacce:

Animal a = new Dog(); a.makeSound();

in quanto io so che è un Dog, ma lo dichiaro con la sua superclasse astratta Animal che implementerà il metodo astratto makeSound(). In questo modo qualora volessi cambiare animale, cambierei solo il nome dell'istanza, facendo rimanere invece costante tutto il resto.

Ancora meglio è astrarre ulteriormente evitando l'istanziazione di una classe concreta hard-code, utilizzando un metodo che assegna l'istanza della variabile a runtime.

Animal a = getAnimal(); a.makeSound();

in questo caso il grado di astrazione è massimo: noi vogliamo che sia un animale e che sappia emettere suoni, poi che animale sia e come fa ad emetterli non è un problema di questa classe.

4.Principio dell'accoppiamento minimo

Due oggetti si dicono minimamente accoppiati quando sono in grado di interagire fra di loro pur conoscendo il minimo possibile della struttura reciproca.

Questo significa che:

sono flessibili all'aggiunta o alla rimozione di oggetti correlati;

per modificare un oggetto non devo modificare anche l'oggetto a questo correlato;

possiamo riusare un oggetto o l'altro in maniera indipendente tra di loro.

Strutturare il codice secondo questo principio ci permette di costruire sistemi OO flessibili che possono facilmente gestire il cambiamento reciproco.

5. Le classi devono essere aperte all'estensione ma chiuse alla modifica

Un buon design deve creare delle classi che sono:

aperte all'estensione: gli oggetti devono essere fatti in modo che sia il più facile estenderli al fine di incorporare una nuova funzionalità;

chiusi alla modifica: una volta che un oggetto funziona correttamente senza bug, ogni sua modifica rischia di immetterne di nuovi. Un buon design deve fare in modo che le modifiche al codice esistente su una funzionalità vecchia siano ridotte al minimo.

Il nostro obiettivo è qunidi quello di crare classi che siano facilmente estendibili al fine di incorporare un nuovo comportamento, senza che questo comportui la modifica del codice pre-esistente.

Qualora vi sia la necessità di cambiare una funzionalità vecchia, il codice deve essere sufficentemente flessibile da poter incoporare la modifica con il minor numero possibile di modifiche, ma solo aggiunte.

Attenzione però, usare questo principio dovunque potrebbe portare ad un aumento di complessità non necessario e a del codice difficile da comprendere. Scegliere con cura le parti gli oggettia cui applicare questo principio.

6. Dipendi dalle classi astratte, non concrete

Questo principio è anche detto il Dependency Inversion Principle e significa che i componenti ad alto livello non devono mai dipendere dai componenti a basso livello e nemmeno il contrario.

Infatti entrambi devono dipendere da componenti astratti.

Un componente si dice ad alto livello quando il suo comportamento è definito in termini di altri componenti a basso livello.

Le seguenti linee guida aiutano a strutturare bene il codice secondo questo principio:

Nessuna variabile deve essere istanziata con l'operatore new. Meglio usare una factory!;

Le classi concrete non dovrebbero avere figli. Se derivo da una classe concreta, significa che dipendo da una classe concreta. E' sempre meglio dipendere da astrazioni;

Non si dovrebbe mai eseguire un override di un metodo implementato dalla propria superclasse: se per poter eseguire il mio codice devo eseguire un override dalla superclasse, significa che questa non era un'astrazione corretta. I metodi implementati nelle superclassi dovrebbero essere condivisi fra tutte le sottoclassi senza mai cambiare.

7. Principio della conoscenza minima

Il principio di minima conoscenza ci obbliga a sviluppare codice in cui gli oggetti comunicano solo con i loro "amici vicini".

In poche parole, ogni oggetto deve comunicare con il minor numero possibile di oggetti diversi e quindi possiede la minima conoscenza possibile del sistema.

Se così non fosse avremmo molte classi tutte correlate fra di loro e il cambiamento di una porterebbe al cambiamento di molte altre.

L'esempio classico di design errato sono metodi concatenati come il seguente:

a.getB().getC().getD()

Tipicamente ogni oggetto dovrebbe invocare solo metodi che appartengono a:

l'oggetto stesso;

oggetti passati come parametro ad un metodo dell'oggetto;

oggetti creati o istanziati da un suo metodo;

un componente dell'oggetto (relazione HAS-A).

8. Il principio di Hollywood

Il principio di Hollywood si può riassumere con la seguente frase:

Non chiamarmi, ti chiamo io

Questo principio ci aiuta ad evitare l'anello di dipendenze, per cui se una classe di alto livello dipende da un componenete di basso livello il quale dipende da uno di alto livello, ho una catena di componenti che rendono il sistema complesso da analizzare.

Nel principio di Hollywood permettiamo ai componenti di basso livello di agganciarsi a dei componenti di alto livello, ma saranno loro a decidere quando questi sono necessari e come (che spiega la frase "non chiamarmi, ti chiamo io").

Esempi di pattern che seguono questo principio sono il Factory, l'Observer e il Template.

9.Principio di singola responsabilità

Un modo alternativo per definire questo principio è: una classe deve avere un solo motivo per cambiare.

Il principio afferma che è necessario assegnare ad ogni classe una ed una sola responsabilità, nel senso che si deve occupare solo di una cosa, un'azione o un oggetto.

Il linguaggio C# permette di creare delle proprietà di una classe particolari, queste vengono chiamate proprietà indexed default. L'idea è poter fare una cosa del genere:

Test t = new Test(); string value = t[1]; // value assume un valore in base a quanto è stato definito nella classe Test

Come si vede dall'esempio indicato sopra, voglio poter accedere ad una classe come se fosse una specie di array, anche se ovviamente questo non è. Spesso questo comportamento viene implementato quando la classe interna ha effettivamente una List o un Dictionary come proprietà e creo questo modo comodo per potervi accedere. Proseguiamo la spiegazione con un esempio, preso da questo link. Assumiamo di avere un oggetto Club con al suo interno una List di oggetti Person, ed inoltre ha una default indexer property per poter accedere a tale lista:

public class Club { /// Collection of Person objects in the Club private List<Person> people = new List<Person>(); public List<Person> People { get; set; } /// The Default property of the Club object public Person this[int index] { get { return people[index]; } set { people[index] = value; } } } public class Person { private string _name; public Person(string name) { _name = name; } public string Name {get; set;} }

In questo modo posso correttamente scrivere il seguente codice:

Club club = new Club(); club.People.Add(new Person("Chris")); // Cambio il nome della prima persona usando il metodo tradizionale club.People[0].Name = "Joe"; // Cambio il nome della prima persona usando il metodo tradizionale usando la default property club[0].Name = "John";

C# offre un metodo estremamente comodo per scrivere più costruttori di una stessa classe che si richiamano l'un l'altro. Questa tecnica è detta constructor chaining.

E' possibile inoltre concatenare costruttori della classe padre tramite il comando base.

Segue un esempio:

class Foo { private int id; private string name; // Costruttore effetivo public Foo(int id, string name) { this.id = id; this.name = name; } // estensione senza parametri in ingresso public Foo() : this(0, "") { } // estensione passando solo l'id public Foo(int id) : this(id, "") { } // estensione passando solo il name public Foo(string name) : this(0, name) { } // Chiamata del costruttore della superclasse public Foo(string name) : base(name) { } }

E' importante sottolineare che, qualora non venga utilizzato l'attributo this, il compilatore considererà l'estensione con il costrutore della superclasse, analogamente ad aver scritto base.

L'ordine con cui questi costruttori viene eseguito segue la logica, in quanto viene chiamato prima il costruttore concatenato, e poi il costruttore effetivamente chiamato dall'esterno.

Per capirne bene il funzionamento indico questo esempio, preso da questo post.

Visual studio permette tre possibili tipologie di compilazione: x86, x64 e any CPU.

Il loro comportamento cambia se si sta compilando su una macchina a 32 bit o su una a 64.

Macchina a 32 bit

Any CPU: il tuo software girerà a 32 bit (in accordo col tuo sistema operativo) e potrà quindi caricare assembly compilati sia con l'opzione "any CPU" che con l'opzione x86. Se carico invece un assembly x64 ottengo un'eccezione BadImageFormatException;

x86: identico a "any CPU";

x64: ottengo sempre un'eccezione BadImageFormatException.

Macchina a 64 bit

Any CPU: il tuo software girerà a 64 bit (in accordo col tuo sistema operativo) e potrà quindi caricare assembly compilati sia con l'opzione "any CPU" che con l'opzione x64. Se carico invece un assembly x86 ottengo un'eccezione BadImageFormatException;

x86: il tuo software girerà a 32 bit e potrà quindi caricare assembly compilati sia con l'opzione "any CPU" che con l'opzione x86. Se carico invece un assembly x64 ottengo un'eccezione BadImageFormatException;

1. Introduzione

Spesso vi è la necessità di eseguire una copia dell'istanza della classe con cui si sta lavorando, ovvero la creazione di una nuova istanza di una classe con lo steso valore di un'istanza esistente.

La procedura di copia non è un'operazione banale che non può essere fatta con un assegnamento, in quanto le classi sono tipi di riferimento e conseguentemente, per esempio, questa operazione

object a = new object {foo="bar"} object b = a b.foo = "new bar" //anche a.foo = "new bar"

porta alla modifica dell'attributo foo sia dell'oggetto a che dell'oggetto b.

2. Il metodo Object.MemberwiseClone()

Questo metodo è un metodo di Object e, conseguentemente, può assere applicato a tutti gli oggetti del nostro sistema.

In particolare il MemberwiseClone metodo crea una copia superficiale (shallow copy) creando un nuovo oggetto e quindi copiando i campi non static dell'oggetto corrente al nuovo oggetto.

Se un campo è di tipo:

Valore: viene eseguita una copia bit per bit del campo;

Riferimento: viene copiato solo il riferimento pertanto sia l'oggetto originale che il suo clone fanno riferimento allo stesso oggetto.

Questo metodo è il metodo base di tutti i metodi clone(), e viene utilizzato per la fase iniziale di shallow copy.

A questo metodo deve spesso seguire un'implementazione personalizzata al fine di ottenere la copia come desiderato (deep copy).

3. L'interfaccia ICloneable

Quando ho la necessità di implementare un metodo clone() che effettui una deep copy e che, conseguentemente, estenda il metodo MemberwiseClone di object posso implementare l'interfaccia ICloneable che contiene un solo metodo, Clone, il quale fornisce un supporto della clonazione aggiuntivo a quello di Object.MemberwiseClone.

L'interfaccia ICloneable richiede semplicemente che l'implementazione del valore restituito dal metodo Clone ritorni una copia dell'istanza dell'oggetto corrente.

Non specifica se l'operazione di duplicazione esegue una copia completa, una copia superficiale, o una via di mezzo, né richiede che tutti i valori della proprietà dell'istanza originale vengano copiati nella nuova istanza.

Tipicamente la struttura di una classe che implementa questa interfaccia è la seguente

public class ClassToClone : ICloneable { public object Clone() { ClassToClone clone = (ClassToClone) this.MemberwiseClone(); // logica di copia dei tipi di riferimento return clone; } }

Questo articolo lo trovate nel nuovo sito https://codicepragmatico.it/

---> Come utilizzare i thread in C#

La parte introduttiva e conclusiva di questo articolo proviene dal libro C# 5(ISBN 978-8820352530), la seconda parte invece dalla documentazione ufficiale.

1. Introduzione

Quando richiediamo l'esecuzione di un programma, il sistema operativo crea un'istanza di un particolare oggetto del kernel chiamato process, a cui assegna un ben definito (e isolato) spazio di indirizzamento in memoria.

Un processo, di per sé, non è in grado di eseguire alcun codice e svolge il compito di puro e semplice contenitore di quelle che potremmo definire come le entità funzionali elementari del sistema operativo: i thread.

Ogni processo dispone di almeno un thread, chiamato primary thread, al termine del quale esso viene distrutto, liberando lo spazio di memoria e le risorse a esso assegnate.

Il normale ciclo di vita di un'applicazione consiste nell'esecuzione sequenziale di numerosi blocchi di codice richiamati dal thread principale, che a loro volta possono richiamare ulteriori blocchi di codice.

Quando questo avviene, il metodo chiamante risulta ovviamente bloccato fintanto che la routine invocata non giunge al termine: si tratta di un operazione non sempre percorribile in quanto appesantirebbe notevolmente l'utilizzo delle applicazioni.

Fortunatamente ogni thread ha la possibilità di assegnare ad un thread secondario l'esecuzione di un metodo; in questo caso, la chiamata a quest'ultimo ritorna immediatamente il controllo al thread chiamante e i due blocchi di codice possono effettivamente essere eseguiti in parallelo.

2. Esempio applicativo

La classe System.Threading.Thread viene usata per lavorare con i thread.

Quando un programma viene lanciato, viene creato automaticamente il corrispettivo thread principale, mentre i thread che vengono creati dallo sviluppatore tramite la classe Thread sono chiamati thread figli.

Nell'esempio riportato di seguito, viene illustrato come creare un thread parallelo ausiliario, da utilizzare per l'elaborazione in parallelo con il thread primario.

Vogliamo creare una classe chiamata Worker che contiene il metodo DoWork che verrà eseguito dal nostro thread di lavoro. Questo è essenzialmente la funzione Main del thread.

Quando verrà eseguito, il thread di lavoro chiamerà questo metodo e terminerà automaticamente quando il metodo verrà restituito.

public void DoWork() { while (!_shouldStop) { Console.WriteLine("worker thread: working..."); } Console.WriteLine("worker thread: terminating gracefully."); }

La classe Worker contiene inoltre un altro metodo utilizzato per indicare che DoWork deve essere restituito, questo metodo, denominato RequestStop, è analogo al seguente

public void RequestStop() { _shouldStop = true; }

Il metodo RequestStop assegna semplicemente l'attributo _shouldStop a true.

Poiché questo attributo è controllato dal metodo DoWork, si ottiene l'effetto indiretto di causare la restituzione di DoWork terminando in questo modo il thread di lavoro.

È tuttavia importante tenere presente che DoWork e RequestStop verranno eseguiti da thread differenti.

DoWork viene eseguito dal thread di lavoro, mentre RequestStop viene eseguito dal thread primario, quindi l'attributo _shouldStop viene dichiarato volatile, come riportato di seguito

private volatile bool _shouldStop;

La parola chiave volatile avvisa il compilatore che più thread accederanno al membro dati _shouldStop e che pertanto non deve formulare ipotesi di ottimizzazione sullo stato di questo membro.

Il modificatore volatile è utilizzato in genere per un campo al quale accedono più thread senza ricorrere all'istruzione lock per la serializzazione dell'accesso.

L'utilizzo di questo modificatore è così comodo perché _shouldStop è un valore bool. Se tuttavia questo membro dati fosse un oggetto complesso, l'accesso da più thread genererebbe un danneggiamento dei dati.

Prima di creare il thread di lavoro, la funzione Main crea un oggetto Worker e un'istanza di Thread.

L'oggetto thread viene configurato per utilizzare il metodo Worker.DoWork passando al costruttore Thread un riferimento a questo metodo, come riportato di seguito

Worker workerObject = new Worker(); Thread workerThread = new Thread(workerObject.DoWork);

A questo punto, anche se l'oggetto thread esiste ed è configurato, questo non è ancora stato creato, per fare ciò è necessario lanciare il metodo Start

workerThread.Start();

A questo punto il sistema avvia l'esecuzione del thread di lavoro, ma in modo asincrono rispetto al thread primario. La funzione Main continua infatti ad eseguire immediatamente il codice mentre il thread di lavoro viene sottoposto contemporaneamente a inizializzazione.

Per evitare che Main tenti di terminare il thread di lavoro prima che venga eseguito, la funzione Main esegue un ciclo finché la proprietà IsAlive dell'oggetto thread di lavoro non viene impostata su true:

while (!workerThread.IsAlive);

Successivamente il thread primario viene interrotto brevemente con una chiamata a Sleep.

In questo modo la funzione DoWork del thread di lavoro eseguirà il ciclo all'interno del metodo DoWork per alcune iterazioni prima che la funzione Main esegua altri comandi

Thread.Sleep(1);

Trascorso un millisecondo, Main segnala all'oggetto thread di lavoro che deve terminare utilizzando il metodo Worker.RequestStop descritto in precedenza

workerObject.RequestStop();

È inoltre possibile terminare un thread da un altro thread utilizzando una chiamata a Abort. In questo modo il thread interessato viene terminato in modo forzato anche se non ha completato l'attività e non consente la pulitura delle risorse.

Infine la funzione Main chiama il metodo Join sull'oggetto thread di lavoro. Tramite questo metodo il thread corrente si blocca oppure attende finché non termina il thread rappresentato dall'oggetto.

Pertanto Join non verrà restituito finché non viene terminato, il thread di lavoro

workerThread.Join();

Il metodo Join accetta come parametro anche un timeout, che rappresenta il tempo massimo di attesa al termine del quale proseguire con l'applicazione.

Di seguito è riportato l'esempio completo.

using System; using System.Threading; public class Worker { // Questo metodo viene passato a costruttore come delegato // alla inizializzazione della classe Thread public void DoWork() { while (!_shouldStop) { Console.WriteLine("worker thread: working..."); } Console.WriteLine("worker thread: terminating gracefully."); } public void RequestStop() { _shouldStop = true; } // Volatile permette di evitare il lock su attributi booleani // che vengono acceduti da più thread private volatile bool _shouldStop; } public class WorkerThreadExample { static void Main() { Worker workerObject = new Worker(); Thread workerThread = new Thread(workerObject.DoWork); workerThread.Start(); Console.WriteLine("main thread: Starting worker thread..."); // Aspetta fino a che il thread non viene ativato while (!workerThread.IsAlive); // Aspetto 1ms in modo che il worker faccia qualcosa Thread.Sleep(1); workerObject.RequestStop(); // Blocco il thread corrente fino a che il worker // non viene terminato con successo workerThread.Join(); Console.WriteLine("main thread: Worker thread has terminated."); } }

L'output di questo programma è il seguent

main thread: starting worker thread... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: working... worker thread: terminating gracefully... main thread: worker thread has terminated

3. Il ThreadPool

Nello sviluppo di un'applicazione multithreading dobbiamo tenere presente che:

ogni thread consuma risorse di sistema ed impiega una certa quantità di memoria

la creazione e la distruzione di un thread sono, in generale, operazioni onerose

Per limitare questi inconvenienti posso evitare di distruggere un thread ogni volta che questi abbia terminato l'esecuzione di mantenerlo attivo per un certo periodo di tempo in stato idle, in modo che possa essere riutilizzato in seguito.

Il CLR mette a disposizione un contenitore, chiamato ThreadPool, all'interno del quale mantiene la lista di thread attivi e tramite il quale permette di gestire le code dei task che vengono ad esso via via assegnati.

La classe statica ThreadPool espone il metodo QueueUserWorkItem, che accetta un delegate di tipo WaitCallback, tramite il quale possiamo accodare un nuovo task da gestire in parallelo.

Sottolineo che la sincronizzazione dei task eseguiti in questo modo è implicita e non richiede alcun accorgimento di codice: non essendo disponibile alcuna istanza di Thread, non è possibile usare il metodo Join per poterne attendere la conclusione.

Allo scopo, possiamo utilizzare la classe ManualResetEvent.

public class Example { public static void Main() { // Inserisco il metodo nel ThreadPool, // questo viene fatto partire automaticamente //senza l'utilizzo di Start, // e termina senza l'utilizzo di Join ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc)); Console.WriteLine("Main thread does some work, then sleeps."); // Inserisco uno Sleep in quanto, altrimenti, // il programa (quindi il main thread) terminerebbe, // portando ad un abort anche di tutti i suoi thread figli Thread.Sleep(1000); Console.WriteLine("Main thread exits."); } // This thread procedure performs the task. static void ThreadProc(Object stateInfo) { Console.WriteLine("Hello from the thread pool."); } } // L'output dell'applicazione sarà il seguente: // Main thread does some work, then sleeps. // Hello from the thread pool. // Main thread exits.

4. Modello di programmazione asincrono

Il comando BeginInvoke permette di eseguire delegate in maniera asincrona, in quanto questo ritorna immediatamente il controllo al thread chiamante e parallelamente fa partire il codice del delegato.

Internamente il BeginInvoke utilizza il threadPool del CLR.

Ci sono due fondamentali differenze tra usare questo metodo e le classi Thread o ThreadPool illustrate in precedenza:

il passaggio di parametri al metodo asincrono avviene in maniera tipizzata, mentre con Thread o ThreadPool l'eventale parametro è sempre object;

i delegate risultano particolarmente** comodi per intercettare il termine dell'elaborazione parallela** e, in particolare, per recuperare il risultato.

Esistono tre diverse modalità per gestire l'esecuzione parallela e recuperarne il risultato, descritte di seguito.

4.1 Utilizzo del metodo EndInvoke

Insieme al metodo BeingInvoke indicato in precedenza, ogni delegato espone anche il metodo EndInvoke che può essere utilizzato per attendere la conslusione dell'operazione asincrona e recuperarne il risultato. BeginInvoke restituisce un oggetto IAsyncResult che può essere utilizzato per monitorare l'avanzamento della chiamata asincrona ed inoltre viene passato come parametro al metodo EndInvoke.

EndInvoke blocca effetivamente in thread in esecuzione fino al termine dell'operazione asincrona, consentendoci quindi di sincronizzare i due thread.

Qualora il delegate preveda un valore di ritorno, EndInvoke lo restituisce come output.

4.2 Utilizzo di IAsyncResult e polling

Il metodo BeginInvoke restituisce un ogetto che implementa l'interfaccia di tipo IAsyncResult.

La proprietà più importante di questo oggetto è AsyncWaitHandle che restituisce un oggetto di tipo WaitHandle, analogo al ManualResetEvent indicato in precedenza.

Tramite questo metodo è possibile implementare un algoritmo di polling per verificare quando un thread ha concluso il suo lavoro nel seguente modo

while(!asyncResult.isCompleted) { asyncResult.AsyncWaitHandle.WaitOne(200); }

4.3 Utilizzare un metodo di calback

In alcune occasioni vi è la necessità di evitare che sia il metodo chiamante a gestire il termine del thread; in questo caso possiamo configurare il delegate in modo che esegua un metodo di callback, passando il metodo come secondo parametro al BeginInvoke.

La firma del metodo di callback deve rispettare quella del delagte AsyncCalback, quindi deve ritornare void e prendere come unico parametro in ingresso un oggetto di tipo IAsyncResult

5. Operazioni cross-thread con Windows Form

5.1 Problema

Accedere a dei controlli Windows Forms (quindi andare a eseguire operazioni nel thread di gestione dell'I/O) non è intrinsicamente thread-safe, infatti potrei avere delle inconsistenze nei dati o perfino dei deadlock. E' insicuro chiamare un controllo da un thread che non sia colui che ha creato e gestisce il controllo, senza usare il metodo BeginInvoke. Nell'esempio seguente ho una chiamata non thread safe:

Private Sub setTextUnsafeBtn_Click(ByVal sender As Object, ByVal e As EventArgs) Handles setTextUnsafeBtn.Click Me.demoThread = New Thread(New ThreadStart(AddressOf Me.ThreadProcUnsafe)) Me.demoThread.Start() End Sub ' Effettuo una modifica all'I/O da un thread esterno Private Sub ThreadProcUnsafe() Me.textBox1.Text = "This text was set unsafely." End Sub

Il debugger .NET rileva queste situazioni lanciando un eccezione InvalidOperationException con il messaggio:

Control control name accessed from a thread other than the thread it was created on.

5.2 Soluzione

Per chiamare un controllo Windows Form in modo thread-safe devo effettuare i seguenti controlli:

Controllare la proprietà InvokeRequired della classe

Se InvokeRequired ritorna true, chiamare il metodo BeginInvoke con un delegate con la stessa firma del metodo attuale

Se InvokeRequired ritorna false, chiamare il metodo direttamente

Il metodo InvokeRequired compara il thread ID del thread chiamante con il thread ID del thread corrente: se questi thread sono differenti ritorna True.

'Quando clicco un pulsante creo un thread che chiama un controllo Windows Form in modo, questa volta, sicuro Private Sub setTextUnsafeBtn_Click(ByVal sender As Object, ByVal e As EventArgs) Handles setTextUnsafeBtn.Click Me.demoThread = New Thread(New ThreadStart(AddressOf Me.ThreadProcUnsafe)) Me.demoThread.Start() End Sub ' Effettuo una modifica all'I/O da un thread esterno Private Sub ThreadProcUnsafe() Me.SetText("This text was set safely.") End Sub Delegate Sub SetTextDelegate(text As String) Private Sub SetText(ByVal text As String) If Me.textBox1.InvokeRequired Then Me.BeginInvoke(New SetTextDelegate(AddressOf SetText), New Object() {text}) Else Me.textBox1.Text = text End If End Sub

Se InvokeRequired ritorna True sto quindi facendo una chiamata cross-thread: in questo caso il metodo crea una nuova istanza del delagate che permette di autochiamarsi in modo asincrono dal thread corretto.

6. Tips generici

Questo articolo è una libera traduzione di questo blog post

6.1 I thread condividono le variabili se hanno una reference comune all'istanza dello stesso oggetto

Consideriamo il seguente esempio:

class SomeClass { private bool _isWorkDone; static void Main(string[] args) { SomeClass someClass = new SomeClass(); // Passso il metodo dell'istanza someClass Thread newThread = new Thread(someClass.DoWork); newThread.Start(); // Chiamo il metodo dalla stessa istanza del thread someClass.DoWork(); Console.Read(); } void DoWork() { if (!_isWorkDone) { _isWorkDone = true; Console.WriteLine("Work done"); } } }

Il risultato di questo codice è la scritta "Work done" sullo schermo. Come si può vedere dal codice, il metodo DoWork() viene chiamato da entrambi i thread a partire dalla stessa istanza di SomeClass: come risultato, dato che il campo _isWorkDone non è statico, questo viene condiviso dai due thread. Conseguentemente, "Work done" viene printato a schermo una volta sola.

6.2 Il blocco finally nei thread in background non viene eseguito quando il processo termina

Consideriamo il seguente esempio:

class SomeClass { static void Main(string[] args) { SomeClass someClass = new SomeClass(); Thread backgroundThread = new Thread(someClass.DoWork); backgroundThread.Start(); Console.WriteLine("Closing the program...."); } void DoWork() { try { Console.WriteLine("Doing some work..."); Thread.Sleep(1000); } finally { Console.WriteLine("This should be always executed"); } } }

Questo codice fornisce:

Doing some work... Closing the program...

Questo esempio dimostra come quando il thread principale termina la sua esecuzione, il campo finally del thread in background non viene eseguito. Non considerare questa eccezione può portare numerodi problemi quando ho lavori di dispose() nel blocco finally di un thread, che non verrebbero lanciati portando, in questo caso, a dei memory leak difficili da individuare

6.3 I valori trovati da lambda espressioni sono anch'essi condivisi

Consideriamo il seguente codice:

class SomeClass { static void Main(string[] args) { for (int i = 0; i < 10; i++) { Thread thread = new Thread(()=> Console.Write(i)); thread.Start(); } Console.Read(); } }

Noi ci aspettiamo un risultato come 0123456789. Il risultato ottenuto è invece assolutamente non deterministico! Il trucco è che la variabile i si riferisce alla stessa locazione di memoria della variabile iterata nell'for, che quindi continua a cambiare. La soluzione è utilizzare una variabile temporanea:

for (int i = 0; i Console.Write(temp)); thread.Start(); }

6.4 Un thread non è influenzato dalla presenza di un try catch esterno alla sua creazione

Consideriamo il seguente codice:

class SomeClass { static void Main(string[] args) { try { Thread thread = new Thread( ()=> Divide(10,0)); thread.Start(); } catch (Exception ex) { Console.WriteLine("An exception occured"); } } static void Divide(int x, int y) { int z = x / y; } }

Questo articolo lo trovate nel nuovo sito https://codicepragmatico.it/

---> C# - I lock

1. Introduzione

La parola chiave lock contrassegna un blocco di istruzioni come sezione critica ottenendo il lock a mutua esclusione. L'esempio seguente illustra un'istruzione lock.

La parola chiave lock impedisce a un thread di entrare in una sezione critica del codice se è già presente un altro thread. Se un altro thread tenta di accedere a un codice bloccato, attenderà (in stato di blocco) finché l'oggetto non verrà rilasciato.

Tipicamente un istruzione lock segue questo template:

private readonly static object obj = new Object(); lock (obj) { // thread unsafe code }

che può essere anche utilizzato black box, senza comprendere il funzionamento interno, ma con la certezza che il codice inserito all'interno del blocco lock verrà acceduto da un thread alla volta, portandolo a diventare thread-safe.

2. La classe Monitor

Il codice indicato sopra viene tradotto dal compilatore di C# 4.0 nel seguente codice:

bool lockWasTaken = false; var temp = obj; try { Monitor.Enter(temp, ref lockWasTaken); // body } finally { if (lockWasTaken) { Monitor.Exit(temp); } }

Per citare la documentazione ufficiale, il metodo Enter di Monitor permette di acquisire l'esclusività di accesso sull'oggetto passato come parametro.

Se un altro thread ha eseguito un Enter sullo stesso oggetto in precedenza ma non lo ha ancora rilasciato tramite il metodo Exit, il thread corrente verrà verrà fermato fino a che l'altro thread non rilascerà l'oggetto.

Il metodo Monitor.Enter indica al thread di aspettare anche all'infinito una risorsa, senza andare mai in timeout.

3. Il parametro in ingresso a lock

Il metodo lock prevede un parametro in ingresso, che spesso viene definito come un new object().

Questo perché l'oggetto che viene passato come parametro serve solo come chiave: se un lock è già stato preso sulla stessa chiave, un ulteriore lock non può essere fatto, altrimenti il lock è permesso.

Questo è il motivo per cui è sbagliato usare le stringhe come chiavi del metodo lock, in quanto queste sono oggetti immutabili e inoltre sono accessibili da altre parti dell'applicazione.

E' necessario invece usare una variabile privata generica, come, per esempio, un istanza della classe Object.

3.1 Non usare lock(this)

E' una pratica di cattiva programmazione utilizzare lock(this) per bloccare l'esecuzione di codice perché generalmente è fuori dal controllo del programmatore chi altro potrebbe stare eseguendo un lock su tale oggetto.

Questo articolo lo trovate nel nuovo sito https://codicepragmatico.it/

---> C# - Gestione degli eventi

1. Introduzione

I delegate vengono usati diffusamente per la gestione degli eventi, cioè quando voglio fare in modo che una classe fornisca delle notifiche ai suoi utilizzatori.

L'azione può essere causata dall'utente, ad esempio il clic su un pulsante oppure può essere generata da un altro programma logico, ad esempio modificare le proprietà di un valore.

La classe che invia (o genera) l'evento è chiamata event sender e le classi che ricevono (o gestiscono) l'evento sono chiamate subscribers.

Il mittente dell'evento non sa quale oggetto o metodo riceverà (dovrà gestire) gli eventi generati.

1.1 Come usare gli eventi

Ora, conosciamo i delegate come dei puntatori a funzione identificati univocamente dala loro firma.

Pensiamo allo scopo degli eventi: vogliamo che un particolare codice venga eseguito quando accade qualcosa da qualche parte nel mio sistema.

Per fare questo, creiamo dei metodi specifici per il codice che vogliamo che venga eseguito.

Il collante tra l'evento e il metodo sono i delegati: l'evento deve internamente memorizzare una lista di puntatori a funzioni da eseguire quando tale evento viene lanciato (aggiunti tramite il comando +=).

Ovviamente se vogliamo chiamare un metodo, dobbiamo sapere quali parametri passare a quest'ultimo! Consideriamo i delegate quindi come dei "contract" tra l'evento e i metodi che vengono chiamati.

Quando dichiaro un evento con la parola chiave event, devo indicare come tipo un delegate, quindi la firma del metodo che deve essere chiamato al lancio dell'evento.

//Definisco una firma che indica un metodo che // prende in ingresso una string e ritorna void public delegate void MyEventHandler(string foo); //Definisco un evento, che ha come tipo il delegate //indicato sopra public event MyEventHandler SomethingHappened; // Quando l'evento chiamato SomethingHappened viene lanciato, // eseguo questo codice, che rispecchia la firma // del delegate descritto sopra protected virtual void OnSomethingHappened(string foo) { //Do some stuff } //Assegno un nuovo delegate che punta a OnSomethingHappened // e lo aggiungo alla lista di eventi chiamata SomethingHappened myObj.SomethingHappened += new MyEventHandler(OnSomethingHappened);

2.La parola chiave event

Per definire un evento, utilizzare event nella firma del metodo che genera l'evento e specificare il tipo di delegato questo ultimo.

In genere, per generare un evento, si aggiunge un metodo contrassegnato come protected e virtual chiamandolo OnEventName.

Il seguente esempio mostra come dichiarare un evento denominato ThresholdReached: l'evento viene associato al delegato con il EventHandler e viene generato in un metodo denominato OnThresholdReached.

class Counter { public event EventHandler ThresholdReached; protected virtual void OnThresholdReached(EventArgs e) { EventHandler handler = ThresholdReached; if (handler != null) { handler(this, e); } } // provide remaining implementation for the class }

3. Utilizzare i delegate del .NET

Negli esempi precedenti non abiamo posto particolare attenzione sulla firma che deve avere il delegate; .NET consiglia di seguire però questo standard per la definizione dei delegate:

delegate void MyEventHandler(object sender, EventArgs e);

quindi quando sollevo l'evento devo obbligatoriamente fornisce la classe che l'ha sollevato e degli argomenti di evento.

Il .NET fornisce un delegate apposito, chiamato EventHandler.

Il secondo argomento è un'istanza della classe EventArgs, si tratta di un tipo che non contiene aluna informazione ma la cui adozione è congliata per un requisito di forma che vedremo fra poco.

Il modo più semplice di valorizzarlo è tramite il suo campo statico Empty:

myMethod(this, EventArgs.Empty)

Qualora volessimo fornire all'evento ulteriori informazioni di stato, conviene creare una classe personalizzata che derivi da EventArgs il cui nome convenzionalmente termina con tale suffisso.

1. Introduzione

La parte introduttiva dell'articolo è presa direttamente dala documentazione ufficiale MSDN.

Un delegate è un tipo che incapsula un metodo, simile a un puntatore a funzione in C e C++.

A differenza dei puntatori a funzione, tuttavia, i delegati sono orientati a oggetti, indipendenti dai tipi e sicuri.

Un delegate deve essere usato per comunicare all'utilizzatore della classe sviluppata: "Sentiti libero di usare qualsiasi metodo che rispetta la firma che ti fornisco e questo verrà chiamato correttamente".

I delegate sono utili per offrire all'utilizzatore dei miei oggetti l'abilità di personalizzarne il comportamento, separando in ogni caso la classe dal suo utilizzatore.

Spesso è possibile ottenere lo stesso comportamento con modalità alternative all'utilizzo dei delegate (un esempio è l'utilizzo del pattern Strategy), ma spesso questi sono il modo più semplice e pulito per ottenere questi comportamenti.

Nell'esempio seguente viene dichiarato un delegato denominato Del che può incapsulare un metodo che accetta una stringa come argomento e restituisce void:

public delegate void Del(string message);

Un oggetto delegato viene normalmente creato in due modi:

fornendo il nome del metodo di cui il delegato eseguirà il wrapping

con un metodo anonimo (funzioni lambda)

I parametri passati al delegato dal chiamante vengono passati al metodo e il valore restituito, se presente, dal metodo viene restituito al chiamante dal delegato.

Se creasi una funzione con la stessa firma del delegato, posso richiamarla in questo modo:

//Stessa firma del delegate public static void DelegateMethod(string message){ System.Console.WriteLine(message); } // Istanzio un oggetto di tipo Del con la funzione sopra Del handler = DelegateMethod; // Chiamo la funzione handler("Hello World");

Poiché l'istanza del delegato è un oggetto, può essere passata come parametro o assegnata a una proprietà; in questo modo un metodo può accettare un delegato come parametro e chiamare il delegato in un secondo momento.

Questa operazione è nota come callback asincrono ed è un metodo comune per notificare un chiamante al termine di un processo lungo.

Quando un delegato viene usato in questo modo, per il codice che usa il delegato non è richiesta alcuna conoscenza dell'implementazione del metodo in uso. La funzionalità è simile all'incapsulamento fornito dalle interfacce.

Un altro utilizzo comune dei callback è la definizione di un metodo di confronto personalizzato e il passaggio di tale delegato a un metodo di ordinamento. Consente al codice del chiamante di entrare a far parte dell'algoritmo di ordinamento. Nell'esempio di metodo seguente viene usato il tipo Del come parametro:

public void MethodWithCallback(int param1, int param2, Del callback) { callback("The number is: " + (param1 + param2).ToString()); }

È quindi possibile passare il delegato creato in precedenza a tale metodo:

MethodWithCallback(1, 2, handler);

E ottenere come risultato:

The number is: 3

2. Multicasting

Assumiamo di aver definito la seguente classe

public class MethodClass { public void Method1(string message) { } public void Method2(string message) { } }

Un delegato può chiamare più di un metodo, quando viene richiamato. Questo processo viene definito multicasting. Per aggiungere un ulteriore metodo all'elenco dei metodi del delegato (l'elenco chiamate), è necessario semplicemente aggiungere due delegati usando gli operatori addizione o di assegnazione di addizione ("+" o "+=").

Ad esempio:

MethodClass obj = new MethodClass(); Del d1 = obj.Method1; Del d2 = obj.Method2; Del d3 = DelegateMethod; //Both types of assignment are valid. Del allMethodsDelegate = d1 + d2; allMethodsDelegate += d3;

A questo punto allMethodsDelegate contiene tre metodi nel relativo elenco chiamate: Method1, Method2 e DelegateMethod.

Quando si richiama allMethodsDelegate, tutti e tre i metodi vengono chiamati nell'ordine.

Se il delegato usa parametri di riferimento, il riferimento viene passato in sequenza a ciascuno dei tre metodi a turno e le eventuali modifiche apportate da un solo metodo saranno visibili al metodo successivo.

Per rimuovere un metodo dall'elenco chiamate, usare l'operatore di decremento o l'operatore di decremento di assegnazione ("-" o "-="'). Ad esempio:

//remove Method1 allMethodsDelegate -= d1; // copy AllMethodsDelegate while removing d2 Del oneMethodDelegate = allMethodsDelegate - d2;

I delegati multicast vengono ampiamente usati nella gestione degli eventi.

3. Metodi anonimi ed espressioni lambda

(questa sezione proviene da questo post) Di solito per assegnare una funzione a un delegato si scrive la funzione separatamente e si assegna al delegato il nome della funzione, invece con i metodi anonimi si può assegnare direttamente la funzione stessa, ecco un esempio:

delegate int MyDelegate(int a); ... MyDelegate d = delegate(int a) { return a * 10; }

In questo modo non è necessario creare un metodo apposta. I metodi anonimi possono essere utili in vari casi ad esempio per passare la funzione di avvio di un thread.

Thread t = new Thread( delegate() { thread code ... ; }); t.Start();

Una particolare forma di metodo anonimo sono le lambda expression utilizzate ad esempio in LINQ.

Nelle espressioni lambda compare l' operatore lambda "=>" che si legge "fino a", alla sua sinistra vi sono i parametri di input (possono mancare) e alla sua destra il codice del metodo, che spesso si riduce ad una espressione, ma può essere complesso a piacere, quindi:

parametri => metodo

Ora assumiamo di aver definito il seguente delegato:

delegate int MyFunc(int i);

Questo può essere inizializzato con due modalità, un metodo anonimo o una espressione lambda:

// Esempio con metodo anonimo: MyFunc p = delegate(int i) { return i * 10; } // La stessa cosa con una lambda expression MyFunc p = i => i* 10;

In questo caso il compilatore deduce il tipo di 'i' e del valore di ritorno in base al tipo del delegato.

Qualora via siano più parametri scrivo

(x, y) => x + y;

Si possono specificare anche i tipi dei parametri in ingresso quando il compilatore non li può dedurre:

(double x, string s) => s.Length + x;

Infine quando non vi sono parametri si usano le parentesi vuote:

() => DateTime.Now.Year % 2000;

Se invece il metodo contiene più parametri devo racchiuderlo tra parentesi graffe:

p => { int a = p * 2; return a + 1; }

4. I delegate e i generics

Essendo i delegate delle classi, è possibile sfruttare i generics per creare delle strutture facilmente riutilizzabili e versatili.

All'interno del framework .NET sono presenti un gran numero di delegate generici già fatti da poter riutilizzare, in particolare seguenti: - Action: Action<TParameter>: un delegate che prende da 0 a 8 parametri in ingresso e non ritorna nulla - Func: Func<TParameter, TResult>: un delegate che prende da 0 a 8 parametri in ingresso e che ritorna un valore o una referenza (di tipo TResult) - Predicate: è un wrapper di Func<T, bool>, viene usata per il compare di oggetti.

Analizziamoli uno ad uno.

4.1 Func<TParameter, TOutput>

Func è logicamente simile all'implementazione base dei delegate. La differenza è il modo in cui questa viene dichiarata:

Func<string, int, int> tempFuncPointer;

I primi due parametri sono i parametri in ingresso del metodo, mentre l'ultimo parametro è un parametro in out che deve essere il tipo di dato di ritorno dal metodo.

Func<string, int, int> tempFuncPointer = tempObj.FirstTestFunction; int value = tempFuncPointer("hello", 3);

4.2 Action<TParameter>

Action è usato quando la funzione non ha parametri in uscita.

Action<string, int> tempActionPointer;

Analogamente a Func, i parametri indicati sono i parametri in ingresso alla funzione, con la differenza che questa non ne ritorna nessuno.

Action<string, int> tempActionPointer = tempObj.ThirdTestFunction; tempActionPointer("hello", 4);

4.3 Predicate<in T>

Predicate è un tipo Func che ritorna un valore booleano. E' spesso usato nell'analizi di liste di oggetti.

La dichiarazione è la seguente

Predicate<Employee> tempPredicatePointer;

in questo caso la funzione tempPredicatePointer prende in ingresso un oggetto Employee e ritorna true se Employee.age < 27:

public bool FourthTestFunction(Employee employee) { return employee.Age < 27; }

5. Delegate come interfacce anonime

La seguente idea proviene da questo post di Mark Seemann.

I delegate possono essere visti a tutti gli effetti come interfacce anonime formate da un solo metodo.

Consideriamo un semplice esempio, ho la classe MyClass che che possiede un metodo DoStuff. Questo metodo prende in ingresso un oggetto astratto (IMyInterface) che deve avere il metodo DoIt il quale, data una stringa, fornisce un intero.

Nella programmazione ad oggetti classica abbiamo:

public interface IMyInterface { int DoIt(string message); } public string DoStuff(IMyInterface strategy) { return strategy.DoIt("Ploeh").ToString(); }

Ma definire una nuova interfaccia solo per fare questo non è necessario, possiamo utilizzare il tipo Func<string, int> nel seguente modo:

public string DoStuff(Func<string, int> strategy) { return strategy("Ploeh").ToString(); }

Questo metodo ci risparmia sia di definire una nuova interfaccia, che di implementare tale interfaccia per definire il metodo DoStuff.

Possiamo invece definire il codice scritto sopra con una lambda function:

string result = sut.DoStuff(s => s.Count());

Ovviamente questa tecnica funziona bene quando ho l'astrazione di un singolo metodo: appena la mia struttura prevede l'introduzione di un secondo metodo, l'utilizzo di un interfaccia o di una classe astratta è obbligatorio.

6. Delegate per evitare lo switch case

In accordo con la antiifcampaign è una pratica di buona programmazione ridurre al minimo l'utilizzo degli if basati sul confronto tra una variabile e n costanti, come nel seguente esempio:

if(input == "foo") { Writeln("some logic here"); } else if(input == "bar") { Writeln("something else here"); } else if(input == "raboof") { Writeln("of course I need more than just Writeln"); }

Esistono due modalità di buona programmazione che eliminano questo caso:

il pattern strategy (che approfondirò in un articolo successivo);

i delegate.

Analizziamo il secondo metodo: creiamo un dizionario che associa una stringa ad una funzione delegata

delegate void DoStuff(); IDictionary<string, DoStuff> dict = new Dictionary<string, DoStuff>(); dict["foo"] = delegate { Console.WriteLine("some logic here"); }; dict["bar"] = delegate { Console.WriteLine("something else here"); }; dict["raboof"] = delegate { Console.WriteLine("of course I need more than just Writeln"); };

Ogni funzione presente come valore nel dizionario indica una logica da implementare nell'if.

Per richiamare la funzione corretta in base alla variabile input basta eseguire il seguente codice:

Questo articolo è una libera traduzione di quanto trovato in questo articolo

Git possiede un comando estremamente potente dal nome singolare: git cherry pic.

La documentazione su tale comando è chiara: dato uno o più commit (qualsiasi) del grafo rappresentante la repository, applica i cambiamenti apportati da ognugno ad un branch, creando un nuovo commit per ognuno di essi.

Per capire bene il funzionamento è importante sottolineare che un commit è identificato univocamente sia dal suo contenuto che dalla sua storia.

Conseguentemente due commit che hanno lo stesso contenuto ma che hanno due padri diversi, per git sono trattati come due commit diversi, senza alcuna relazione tra di loro.

Il comando cherry pic prende in ingresso un commit (per semplicità lavoro con un singolo commit, la discussione poi è analoga per n commit) e applica i cambiamenti che questo ha effettuato sul commit padre, ad un qualsiasi nodo foglia del grafo, creando un nuovo commit con un nuovo SHA-1.

Assumiamo di avere il seguente grafo:

Asummiamo che l'HEAD punti al nodo H del grafo. Effettuando un

git cherry-pick E

Questo articolo è una libera traduzione di quanto trovato sula documentazione di git a riguardo.

1. Introduzione

Spesso quando si sta lavorando ad un progetto, si potrebbe avere la necessità di cambiare branch in breve tempo.

Il problema è che git impedisce di cambiare branch se ho effettuato dei cambiamenti al codice non committati, per evitare che questi vadano persi nel cambio.

Allo stesso modo è scomodo e sbagliato committare un lavoro eseguito a metà solo per avere la possibilità di cambiare un branch.

Per risolvere questi problemi viene in aiuto git con il suo comando stash.

Lo stashing prende tutto quello che è presente nella mia working directory (quindi le modifiche tracked e i file nell'area di staging) e li salva in uno "stash" di cambiamenti in sospeso, che potrano essere recuperati in qualsiasi momento.

2. Aggiunta, visualizzazione e applicazione dello stash

Ora, assumiamo di aver lavorato su dei file nella working directory e di essere in questo stato:

$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: lib/simplegit.rb #

Ora, io voglio cambiare branch ma non voglio effettuare un commit di queste modifiche, effettuo quindi uno stash.

$ git stash Saved working directory and index state \ "WIP on master: 049d078 added the index file" HEAD is now at 049d078 added the index file (To restore them type "git stash apply")

Ora la mia working directory è pulita:

$ git status # On branch master nothing to commit, working directory clean

Ora posso tranquillamente cambiare branch.

Per visualizzare tutti gli stash che ho memorizato, basta utilizzato il git stash list:

$ git stash list stash@{0}: WIP on master: 049d078 added the index file stash@{1}: WIP on master: c264051 Revert "added file_size" stash@{2}: WIP on master: 21d80a5 added number to log

In questo caso ho tre stash memorizzati, posso appplicare in qualsiasi di questi stash al commit attuale tramite il

git stash apply

che di default applica l'ultimo stash aggiunto alla lista.

Se volessi applicare invece uno degli stash più vecchi, posso specificarlo tramite il suo nome nel seguente modo:

git stash apply stash@{2}

Posso anche applicare uno stash ad un branch che non è il suo branch di origine, ci pensa git ad effetuare un merge eventuale dei conflitti.

Per eliminare uno stash posso usare il metodo:

git stash drop stash@{0}

Questo articolo lo trovate nel nuovo sito https://codicepragmatico.it/

---> Cosa significa Detached HEAD e come uscirne

Questo articolo è una libera traduzione di questo post.

Git ha uno stato chiamato 'detached HEAD' che all'inizio risulta di difficile comprensione.

L'unica notizia che viene subito fornita ai programmatori è di non committare su una detached HEAD. In questo articolo cerchiamo di spiegare meglio il funzionamento di questo dettaglio di git.

1. L'oggetto HEAD

Partiamo con la descrizione di HEAD: questa è tipicamente un puntatore all'ultimo commit di un branch.

Per visualizzare dove punta l'HEAD attuale basta eseguire un

cat .git/HEAD >> ref: refs/heads/master

che indica che l'HEAD attuale punta all'ultimo commit del master. Ora, quando cambio branch tramite un

git checkout branchname

HEAD punterà quindi all'ultimo commit di 'branchname', e questo significa che il comando eseguito in precedenza fornirà i seguenti risultati:

cat .git/HEAD >> ref: refs/heads/branchname

Questo è il comportamento standard.

2. Detached-HEAD

Ora, assumiamo di voler visualizzare lo stato del codice ad un nodo del grafo che non è l'ultimo commit di un branch locale, questo porta al fatto che HEAD non è più un puntatore all'ultimo commit di un branch locale, ma è un puntatore allo SHA-1 di un commit specifico.

Questo stato è detto di detached HEAD, in quanto ogni commit che viene eseguito in questo stato non appartiene a nessun branch (oppure possiamo considerarlo come appartenente ad un branch anonimo).

Se così non fosse, un commit eseguito dopo un checkout ad un nodo del grafo che non è l'ultimo, eliminerebbe tutti i nodi succesivi.

Per esempio i seguenti comandi portano tutti ad uno stato di detached HEAD:

git checkout master^ # parent of master git checkout HEAD~2 # grandparent of current HEAD git checkout origin/master # a non-local branch git checkout tagname # since you cant commit to a tag!

3. Recuperare da uno stato di detached HEAD

Qualora incontrassi l'errore tipico di effettuare alcuni commit in uno stato di detached HEAD (e quindi su un branch anonimo), posso recuperare facilmente con il seguente comando:

git checkout -b newbranch

che crea un nuovo branch chiamato 'newbranch' spostando tutti i commit in questo branch. Il branch anonimo ora diventa un branch classico.

4. Come recuperare dei commit perduti

Assumiamo ora di non accorgersi di stare committando in un branch anonimo e di cambiare branch:

git checkout someoldbranch

Ora HEAD è un riferimento simbolico a 'someoldbranch' e il suo valore precendente (lo SHA-1 dell'ultimo commit eseguito in detached HEAD) è stato sovrascritto. Per come sono descritte le cose sembra che i commit ora siano definitivamente persi, ma per fortuna così non è. I commit infatti esistono ancora da qualche parte, bisogna solo andarli a recuperare. Git possiede un comando chiamato 'reflog' che permette di recuperare tutto quello che è stato fatto sulla repository negli ultimi 30 giorni, sopratutto lo SHA-1 del commit perduto.

git reflog show HEAD@{now} -10 dcd215b... HEAD@{5 minutes ago}: commit (amend): 0-terminology: the malloc analogy added, plus 5ce8bfe... HEAD@{11 minutes ago}: commit: 0-terminology: the malloc analogy added, plus 3d93420... HEAD@{11 minutes ago}: rebase -i (pick): updating HEAD 7fdae94... HEAD@{11 minutes ago}: checkout: moving from master to 7fdae94815d6c676742c9984132b7b9e71a57f98 3d93420... HEAD@{13 minutes ago}: rebase -i (squash): updating HEAD c55900c... HEAD@{13 minutes ago}: rebase -i (pick): updating HEAD 7fdae94... HEAD@{13 minutes ago}: checkout: moving from master to 7fdae94815d6c676742c9984132b7b9e71a57f98 e9955c8... HEAD@{14 minutes ago}: commit: s 97ab644... HEAD@{20 minutes ago}: commit: autogen c55900c... HEAD@{23 minutes ago}: commit (amend): 0-terminology: the malloc analogy added, plus

Una volta trovato lo SHA-1 che mi serviva, andiamo a recuperarlo e inseriamolo in un nuovo branch:

Questo articolo è una traduzione del famoso post di Vincent Driessen che espone un pattern di branching per strutturare nel modo migliore lo sviluppo di un progetto usando git.

1. Introduzione

Git (e questo modello di lavoro) lavorano bene con questo schema di sviluppo: Questo modelo consiste in una repository remota centrale effettiva (chiamata origin per convenzione) e ogni sviluppatore esegue dei pull e dei push a tale repository.

Ma oltre ai push-pull centralizzati, ogni sviluppatore può inoltre eseguire dei pul/push da latri sviluppatori direttamente: questo può essere utile se, per esempio, due o più sviluppatori stanno lavorando su una grande feature nuova e volgiono collaborare senza pushare sull'origin prematuramente.

Tecnicamente questa cosa viene fatta tramie il setup di un remote alla repository (locale) di un altro sviluppatore.

Quindi Alice, in questo caso, e definito un git remote che punta ala repository di Bob e viceversa.

2. I branch principali

Il modello di sviluppo classico prevede due branch principali che non devonno essere mai eliminati: master e develop.

Consideriamo origin/master il branch principale remoto, dove HEAD punta sempre al commit di produzione attuale.

Consideriamo origin/develop il branch dove HEAD riflette lo stato con gli ultimi sviluppi conclusi che verranno portati in produzione alla prossima release.

Quando il codice del branch develop raggiunge un punto stabile ed è pronto ad essere rilasciato, tuti i cambiamenti devono essere mergiati sul master e taggati con un numero di release.

Sottolineo che ogni cambiamento che avviene sul master riflette anche l'aggiornamento dela versione in produzione.

E' prassi comune infatti avere un deploy su server dopo il merge di un qualsiasi branch sul master (heroku, per esempio, fornisce questo comportamento nativamente).

3. I branch di supporto

Parallelamente ai nostri due branch princiapli, il modello di svilupo prevede una varietà di branch di supporto per permettere uno sviluppo parallelo di codice tra i vari memri del team.

A differenza dei due branch principali, questi branch hanno sempre vita limitata e dovranno essere eliminati prima o poi.

Esistono tre tipologie di branch:

Feature branches

Release branches

Hotfix branches

Ogni tipologia di branch ha uno scopo specifico e deve seguire una serie di convenzioni.

3.1 Feature branch

Questa tipologia di branch deve partire dal develop e ritornare nel develop e può chiamarsi in qualsiasi modo trane master, develop, release-*, o hotfix-*.

Questi branch sono usati per svilupare nuove feature per release a breve o lungo termine.

Il branch di feature esiste fintantochè la feature di riferimento è in sviluppo, ala fine del suo ciclo di vita questo verrà o mergiato nel develop oppure scartato.

I branch di feature tipicamente esistono solo nelle repository locali degli sviluppatori, non nell'origin.

3.1.1 Creazione di un nuovo feature branch

Per cominciare a lavorare su una nuova feature, creiamo un branch dal develop col seguente comando:

$ git checkout -b myfeature develop Switched to a new branch "myfeature"

Una volta terminato lo sviluppo eseguo un merge del branch sul develop in modo che siano pronti per la successiva release.

$ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop

L'opzione --no-ff porta il merge a creare sempre un nuovo commit di merge ed evita che vengano perse informazioni riguardo l'esistenza storica del branch di feature raggruppando insieme i commit che hanno portato alla creazione della feature.

Se il merge viene eseguito senza l'opzione --no-ff è impossibile per git sapere distinguere quali commit sono stati mergiati dal branch di feature e conseguentemente eseguirne un revert è complesso (è necessario andare a leggere i log uno ad uno).

3.2 Release branche

Questi branch partono dal develop e devono essere mergiati o sia sul develop che sul master e si chiamano, per convenzione, release-*.

Questi branch supportano la preparazione di una nuova release in produzione, permettono picoli bug-fix e preparano i meta-dati per la relase (numero di versione, date di build...).

Eseguendo tutto questo lavoro su un branch di release, sono libero di utilizzare il branch di develop solo per ricevere le feature per la nostra prossima release.

Il momento giusto per far partire un nuovo branch di release dal develop, è quando questo riflette quasi totalmente lo stato dell'applicazione per la prossima release. Tutte le feature che devono essere rilasciate per la prossima versione devono essere mergiate nel develop a questo punto.

E' esattamente alla creazione di un nuovo branch di release che a questa viene assegnata un numero di versione, non prima: il numero di versione da scegliere dovrà seguire le regole di progetto per il cambiamento dei numeri di versione.

3.2.1 Creazione del branch di release

I branch di release sono creati dal branch di develop. Assumiamo, per esempio, che il branch di release abbia versione 1.1.5, alla creazione del branch di release devo decidere se far passare alla versione 1.1.6 o 1.2 o perfino 2.0.

Per esempio, assumiamo di aver scelto 1.2.

$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)

Dopo aver creato il nuovo branch lanciamo bump-version.sh, uno script di shell che deve essere fatto ad-hoc che cambia i file per rifletere la nuova versione.

La nuova versione è poi commitata.

Questo branch può esistere per un periodo di tempo limitato, durante il quale possono esservi applicati dei bug-fix (invece che sul branch di develop) ma l'aggiunta di nuove feature è assolutamente proibita.

3.2.2 Concludere un branch di release

Qaundo lo stato del branch di release è pronto per diventare le relase finale, devo eseguire alcune azioni che descrivo qui.

Per prima cosa, il branch di release deve essere mergiato sul master (ricordo che ogni comit sul master è una nuova release per definizione).

Succesivamente, il commit sul master deve essere taggato per poterlo referenziare in futuro.

$ git checkout master Switched to branch 'master' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2

Alla fine i cambiamenti effetuati nel branch di release devono essere mergiati indietro nel develop, così anche le release future conterranno tali bug-fix.

$ git checkout develop Switched to branch 'develop' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes)

Per concludere definitivamente le release, il branch di release viene eliminato.

$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe).

3.3 Hotfix branche

Questi branch sono gli unici branch che partono dal master e vengono rimergiati sia sul master che sul develop. Per convenzione si chiamano hotfix-*.

I branch di hotfix sono molto simili ai branch di release, con la differenza che non sono previsti.

Questi rispondono ala necessità di risolvere immediatamente ad un problema che si riscontra in produzione (e quindi sul master).

3.3.1 Creazione di un branch di hotfix

La creazione di un branch di hotfix è analoga a quella di un branch di release, con la differenza che questa parte dal master.

$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1. $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)

Una volta che ho fixato il bug, eseguo un commit di quanto efettuato:

$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)

3.3.2 Chiusura di un branch di hotfix

Una volta concluso, il branch deve essere mergiato sia sul master che sul develop. La procedura è analoga ai branch di release.

Mergiamo sul master:

$ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1

E sul develop:

$ git checkout develop Switched to branch 'develop' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive.

L'unica eccezione permessa a questo workflow è che se esiste un branch di release mentre ho un branch di hotfix, quest'ultimo deve essere mergiato sul branch di release invece che sul develop.

4. SourceTree e Git-flow

Questa parte dell'articolo riguarda SourceTree, un popolare client gratuito per git e mercurial.

Dalla versione 1.5 del progetto è presente un bottone chiamato "git flow" che offre una serie di comandi comodi per implementare quanto descritto nell'articolo precedente.

Infatti permette la creazione del branch di develop qualora non esistesse, ed inoltre fornisce un'interfaccia ad alto livello per creare feature, release e hotfix, con tutte le convenzioni indicate sopra, in maniera automatica.

L'istruzione using fornisce una sintassi utile che garantisce l'utilizzo corretto degli oggetti IDisposable. Cominciamo con un esempio:

using (Font font1 = new Font("Arial", 10.0f)) { byte charset = font1.GdiCharSet; }

Font (come File) è un classico esempio di un tipo managed che accede a risorse unmanaged, come handle di file o contesti di dispositivo.

Tutti questi tipi devono implementare l'interfaccia IDisposable.

Quando si utilizza un oggetto IDisposable, è di norma dichiararlo e crearne un'istanza in un'istruzione using.

L'istruzione using chiama il metodo Dispose sull'oggetto nel modo corretto e fa in modo che l'oggetto stesso esca dallo scope non appena viene chiamato il metodo Dispose.

All'interno del blocco using, l'oggetto è di sola lettura e non può essere modificato né riassegnato.

L'istruzione using assicura che venga chiamato il metodo Dispose anche se si verifica un'eccezione mentre vengono chiamati metodi sull'oggetto.

È possibile ottenere lo stesso risultato inserendo l'oggetto in un blocco try e chiamando il metodo Dispose in un blocco finally, in quanto l'istruzione using viene tradotta in questo modo dal compilatore.

Il codice indicato sopra che utilizza il blocco using è esatamente analogo a questo (le parentesi graffe aggiuntive limitano lo scope dell'oggetto):

{ Font font1 = new Font("Arial", 10.0f); try { byte charset = font1.GdiCharSet; } finally { if (font1 != null) ((IDisposable)font1).Dispose(); } }

E' possibile inizializare più istanze nello stesso blocco using, cosa che rende estremamente più leggibile il codice:

using (Font font3 = new Font("Arial", 10.0f), font4 = new Font("Arial", 10.0f)) { // Use font3 and font4. }

E' possibile inizializzare un oggetto e sucessivamente passare l'istanza al bloco using, anche se non è una pratica consigliata in quanto l'oggetto rimane nello scope del metodo anche se probabilmente non ha più accesso alle sue risorse unmanaged e il tentativo di utilizzarlo al di fuori del blocco using pottebbe causare un'eccezione.

Questo articolo è una libera traduzione di questa domanda di stackoverflow.

1. Introduzione

Il metodoDispose()viene usato per liberare risorse non più gestite che non possono essere rilevate dal garbage collector (chiamate in inglese unmanaged, per maggiore chiarezza d'ora in poi userò questo termine).

E' importante sotolineare che il .NET possiede di garbage collector per l'eliminazione delle istanze di clasi non più referenziate, analogamente al Java.

L'eliminazione delle risorse dalla memoria deve essere eseguito ad un certo punto del codice, altrimenti tali risorse rimarrano in RAM e potrebbero portare a dei memory leak.

2. Managed e unmanaged

Per capire la distinzione tra risorse managed e unmanaged basti pensare a questo:

tutti i tipi di variabili che si possono trovare in .NET (quindi su MSDN) sono managed. Il GC conosce tutto di loro e può eliminarle in autonomia;

tutti i tipi che invece non si trovano su MSDN sono unmanaged. Tutte le risorse che sono state create tramite chiamate di PInvoke (Platform Invocation Services) che quindi escono dal confortevole mondo dei tipi .NET è unmanaged e, conseguentemente, si ha anche la responsabilità dela loro eliminazione dalla memoria.

Assumiamo per esempio di avere una variabile di tipo intPtr. Il GarbageCollector non conosce come chiamare il metodo DeleteHandle() (che è il suo metodo tipico di elimminazione di oggetti), ne se chiamare o meno tale metodo.

3. L'interfaccia IDisposable

L'oggetto creato deve esporre un metodo che può essere chiamato dall'esterno che permette di eliminare questa risorsa unmanaged. Questo metodo è chiamato Dispose() e, per rendere più chiara la struttura del codice, esiste un'interfaccia, chiamata IDisposable che ha solo un metodo, il Dipose().

public interface IDisposable { void Dispose() }

Esempio di implementazione del metodo Dispose().

public void Dispose() { Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); }

4. Dipose di oggetti managed

Assumiamo di lavorare con oggetti managed, per esempio una System.Drawing.Bitmap. Ora, questa può occupare anche, per esempio, 250MB di memora.

Ovviamente questo è un oggeto managed e quindi il GC prima o poi lo eliminerà.

Ora, davvero noi vogliamo che ci siano 250MB di memoria occupati per nulla, nell'attesa che eventualmente il GC arrivi e la liberi? Ovviamente no.

Il metodo Dispose() di un oggetto deve quindi eliminare

le risorse unmanaged (perchè è obbligato a farlo)

le risorse managed (perchè può essere utile per l'applicazione stessa)

Aggiorniamo il metodo Dispose()indicato sopra con l'eliminazione anche delle risorse managed, come una connessione a DB e un frame buffer.

public void Dispose() { //Free unmanaged resources Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //Free managed resources too if (this.databaseConnection != null) { this.databaseConnection.Dispose(); this.databaseConnection = null; } if (this.frameBufferImage != null) { this.frameBufferImage.Dispose(); this.frameBufferImage = null; } }

5. Il metodo Finalize()

Assumiamo ora che il programmatore dimentichi di chiamare il metodo Dispose() sull'oggetto che ho creato. Avrò un leak di risorse unmanaged, eventualità ovviamente da evitare! Ovviamente le risorse managed verranno eliminate prima o poi dal GC, anche senza chiamare il metodo Dispose(), portando però alle problematiche descritte sopra.

Vorremo avere un modo per cui, quando il GC elimina il mio oggetto, ne elimini anche le risorse unmanaged senza rendersene conto.

Quando il GC elimina tutti gli oggetti managed, chiama il metodo Finalize() su ogni oggetto. Il GC non conosce il nostro metodo Dispose().

++Per fare in modo che, quando il GC elimina le risorse managed, vengano eliminate anche le risorse unmanaged è l'override del metodo Finalize()++.

In C#, non devo esplicitamente fare un override del metodo Finalize(). Invece per fare ciò scrivo un metodo che ha la stessa sinatssi di un distruttore C++, sarà il compilatore a tradurlo in un implementazione del metodo Finalize().

Per esempio posso avere una situazione analoga (attenzione, l'esempio successivo ha un bug!)

~MyObject() { //we're being finalized (i.e. destroyed), call Dispose in case the user forgot to Dispose(); //<--Warning: subtle bug! Keep reading! }

Il codice indicato sopra ha però un problema: come sappiamo, il GC lavora con un thread in background, conseguentemente non conosce l'ordine in cui due oggetti vengono distrutti.

Conseguentemente è possibile che, nel codice del mio Dispose() gli oggetti managed che sto cercando di eliminare siano a tutti gli effetti già stati eliminati dal GC.

Alle chiamate di:

this.databaseConnection.Dispose();

o

this.frameBufferImage.Dispose();

avrei un crash dell'applicazione, in quanto sto cercando di eliminare risorse che sono già state eliminate.

Conseguentemente devo avere un modo per cui il metodo Finalize() comunica al metodo Dispose() che questo non deve toccare le risorse managed in quanto potrebbero non essere più lì, mentre deve agire normalmente per le risorse unmanaged.

Il pattern standard per ottenere ciò è che sia il metodo Finalize() che il metodo Dispose() chiamino un terzo metodo con un parametro booleano che indica se è stato chiamato dal metodo Dispose() o dal metodo Finalize().

E' prassi comune chiamare questo metodo con la seguente firma:

protected void Dispose(Boolean disposing)

anche se sarebbe più esplicativo scrivere:

protected void Dispose(Boolean itIsSafeToAlsoFreeManagedObjects)

Ottenendo quindi:

public void Dispose() { Dispose(true); //I am calling you from Dispose, it's safe }

e

~MyObject() { Dispose(false); //I am *not* calling you from Dispose, it's *not* safe }

N.b. Se sto facendo l'override di un metodo Dispose()della mia superclasse, devo ricordare di chiamare anche tale metodo:

public Dispose() { try { Dispose(true); //true: safe to free managed resources } finally { base.Dispose(); } }

6. Gestione del Garbage Collector

Per come abbiamo strutturato il codice, quando l'utente chiama il metodo Dispose()su un oggetto, ogni cosa viene eliminata dalla memoria.

Successivamente, quando arriva il Garbage Collector e chiama il metodo Finalize() verrà eseguita una ulteriore chiamata al metodo Dispose() Questa modalità non solo è uno spreco di risorse, ma se il mio oggetto ha riferimenti ad oggeti che sono già stati eliminati dal'ultima chiamta del metodo Dispose() cercherò di eliminarli ancora! Faccio notare che nel codice indicato sopra, ho la rimozione dei riferimenti ad oggetti eliminati:

this.frameBufferImage.Dispose(); this.frameBufferImage = null;

conseguentemente non avrei questo bug, però qualora dimenticassi di assegnare a null la variabile avrei il problema.

Il modo per risolvere questo comportamento è dire al Garbage collector che non deve chiamare il metodo Finalize()di questo oggetto, in quanto le sue risorse sono già state eliminate in precedenza.

Questo comportamento è implementato grazie al metodo GC.SuppressFinalize():

public void Dispose() { Dispose(true); //I am calling you from Dispose, it's safe GC.SuppressFinalize(this); //Hey, GC: don't bother calling finalize later }

7. Perchè non liberare le risorse unmanaged nel Finalize()

In teoria io potre avere l'eliminazione delle risorse unmanaged anche nel metodo Finalize() ma è sempre consigliabile usare il metodo Dispose() Questo perchè il metodo Finalize()viene chiamato solo dal GC, e io non ho idea di quando questo opererà, mi affido alle sue tempistiche per l'eliminazione di oggeti che potrebbero potenzialmente portare a dei leak.

La documentazione di Object.Finalize è infatti chiara: il metodo Finalize()viene chiamato con tempistiche non deterministiche. per avere eliminazione a tempistiche note, è necessario avere un implementazione del metodo Dispose()di IDisposable.

8. Codice Finale

Di seguito indico il pattern completo dell’implementazione di una classe IDisposable.

In questo articolo tratto in maniera estremamente introduttiva i tre comandi fondamentali per l'elaborazione dei file in linux, estremamente utili per la ricerca e l'elaborazione di file tramite terminale.

1. Grep

Grep viene utilizzato per cercare un termine specifico all'interno di un file.

Questo comando è molto utile quando voglio cercare velocemente le linee di un file (o genericamente di uno stream in uscita da un comando) che matchano una certa espressione.

Può fornire inoltre informazioni aggiuntive, come il numero di righe, il numero di match, il nome del file e così via.

Per esempio posso scrivere

$ grep This file.txt Every line containing "This" Every line containing "This"

che cerca tutte le linee contenute nel file file.txt che contengono la parola This.

E' importante sottolineare che il comando grep supporta nativamente le espressioni regolari.

E' possibile evitare l'escaping dei caratteri speciali per le regexp usando l'opzione -E.

1.1 Opzioni utili

opzione significato -i Case insensitive -w whole word: cerca solo parole intere e non sottostringhe -R ricerca ricorsiva tra i file di un path -v Inverso: mostra le linee che non matchano -c Count: conta le linee che matchano -l mostra solo il nome del file che matcha -o Mostra solo il contenuto matchato e non tutta la linea -n Mostra anche il numero di linea oltre che all'output standard -E Extended regexp: permette l'utilizzo di caratteri per regexp [()...] senza usare l'escape

Un esempio di comando grep comodo è il

grep -Rin pattern path/to/search

che permette di ricercare ricorsivamente tra tutti i file e le sottodirectory del path indicato, un determinato pattern, case insensitive ed indicandone il numero di riga.

2. Awk

awk (come sed) è completamente diverso da grep in quanto è un processore di testo: conseguentemente non ha solo l'abilità di trovare una espressione che sto cercando all'interno di un testo, ma possono anche **rimuovere, aggiungere e modificare il testo del file stesso.

awk viene usato in particolare per estrarre dati e reportistica**.

In particolare awk è un intero linguaggio di programmazione costruito originariamente attorno ai file CSV, è molto potente ma è complesso da usare, sopratutto per i task semplici. Un esempio è il seguente

$ awk '{print $2}' file.txt

che permette di printare la seconda colonna del file file.txt.

awk permette di eseguire compiti molto complessi, per esempio assumiamo di avere il file file.txt che contiene i numeri 10, 20, 60.

Il seguente codice permette di ottenere il valore medio dei numeri contenuti in tale file

$ awk 'BEGIN {sum=0; count=0; OFS="\t"} {sum+=$2; count++} END {print "Average:", sum/count}' file.txt Average: 30

3. Sed

sed (come awk) è un processore di testo. Risulta molto utile quando voglio eseguire dei cambiamenti nel contenuto di un file secondo una determinata espressione regolare.

E' meno espressivo di awk ma è più semplice da usare, sopratutto per i compiti piccoli.

Per esempio il seguente codice

$ sed -i 's/cat/dog/' file.txt