C#

.NET Reflector passa di mano

Il futuro di .NET Reflector passa nelle mani di Red Gate! Bod Cramblitt ha postato nel suo blog alcuni dettagli del deal. La frase che interessa ai piu' e' condensata in: "Red Gate will continue to offer the tool for free to the community."

posted @ martedì 26 agosto 2008 06:30 | Feedback (0)

A volte l'eleganza del linguaggio fa la differenza

Poche ore fa stavo rivedendo una 'vecchia' classe che 'simula' il concetto di map. In pratica e' una sorta di dictionary che permette di avere duplicazioni di chiave. Niente di veramente speciale, di fatto usavo una List di KeyValuePair; si pou' fare di meglio, ma qui l'accorcio :-) Per estrarre i valori data una chiave, ho usato il buon vecchio foreach che andava a riempire una lista di stringhe. In altre parole qualcosa del tipo List<string> result = new List<string>(); foreach(KeyValuePair<string, string> parameter in parameters) {   if(parameter.Key.Equals(param))     result.Add(parameter.Value); } return result.ToArray(); Dato che il progetto e' migrato a FX 3.5, ho improvvisato una soluzione LINQ: return parameters.FindAll(kv => kv.Key.Equals(param)).Select(kv...

posted @ martedì 20 maggio 2008 15:43 | Feedback (6)

protected internal e FamAndAssem

Quest'oggi stavo giocando con l'accessibility accessor 'protected internal' e non mi quadrava una cosa. Veniamo al pezzo di codice incriminato: public class B {     protected internal A a; }   internal class A { } Il compilatore generera' un bel errore del tipo "Inconsistent accessibility: field type 'Demo.A' is less accessible than field 'Demo.B.a'". Il compilatore ha sempre ragione ed infatti 'protected internal' vuol dire 'protected' or 'internal'. Essendo la classe A solo internal, l'aggiunta di 'protected' non va bene in quanto ha una visibilita' piu' estesa. Mi son chiesto ma come accidenti posso avere protected and internal dato che sia l'IL (FamAndAdssem) che C++/CLI (protected private) che System.Reflection.Emit lo permettono? La risposta...

posted @ lunedì 17 marzo 2008 07:14 | Feedback (1)

Il problema delle collisioni nelle funzioni di hashing

Una funzione di hashing non e' altro che una funzione che traspone un dato di qualche tipo in un numero (potrebbe non essere un numero, ma qui semplifico) 'relativamente' piccolo, creando una sorta di 'impronta digitale'. E' una funzione one-way nel senso che dal dato si puo' derivare il valore numerico, ma non viceversa. Per questo motivo si presta particolarmente bene per il mondo della security e delle basi dati. Il problema principale delle funzioni di hashing e' rappresentato dalle collisioni. Dato che i dati di input hanno potenzialmente un numero di combinazioni superiore al numero finito di hash possibili,...

posted @ sabato 26 gennaio 2008 17:24 | Feedback (4)

Automatic properties e object initializer

Ok, sto per iniziare con una banalita', soprattutto qui dove vi sono persone in questi dintorni che si cibano di codice C# quotidianamente. La combinazione di automatic properties e object initializer permette di risparmiare parecchie righe di codice. Ad esempio: class Program {   static void Main(string[] args)  {     Console.WriteLine(new Item { Label = "Patate" });   } } public class Item {   public string Label { get; set; }   public override string ToString()  {     return Label;   } } Leggendo alcuni post ci si chiedeva se non era il caso di introdurre una nuova keyword property in...

posted @ giovedì 24 gennaio 2008 15:50 | Feedback (0)