Claudio Brotto

Passando davanti alla libreria di camera mia mi sono soffermato ad osservare i libri di informatica, meticolosamente allineati in ordine di argomento nei ripiani più alti (sono una persona abbastanza disordinata, ma la mia "bibliotechina" è un discorso a parte :)).

Da quattro anni a questa parte ne ho comprato un discreto numero (a spanne dovrebbero essere una trentina), e in effetti, a volerli mettere in ordine cronologico di acquisto, rispecchiano abbastanza fedelmente l'andamento dei miei interessi e dei miei impegni sul lavoro.

Mi ha colpito una cosa, in questa rapida rassegna.

I primi 6 o 7 libri sono traduzioni in italiano.

Gli ultimi (con alcune eccezioni, prima fra tutte: alcuni autori sono italiani !) sono tutti versioni originali inglesi.

I motivi, pensandoci, ci sono.

Innanzitutto, col passare del tempo e con l'aumentare dell'esperienza, mi sono trovato a ricercare volumi che semplicemente non sono stati tradotti, o comunque difficili da reperire in versione italiana. Non sto parlando di libri introvabili su argomenti ultra-avanzati: un esempio su tutti è Advanced .NET Remoting di Ingo Rammer, che avevo a suo tempo cercato senza fortuna in versione tradotta, salvo poi ripiegare sull'acquisto on-line via Amazon .

In secondo luogo, spesso i volumi in lingua originale acquistati via Internet costano meno delle relative versioni tradotte che possiamo trovare in libreria. A maggior ragione ora che il cambio euro-dollaro invoglia a fare compere oltre oceano.

Terzo, ma in realtà primo per importanza. Da un po' di tempo preferisco leggere la versione inglese di un testo "tecnico" piuttosto che la sua traduzione.

Non fraintendetemi: ci sono sicuramente traduzioni di ottima qualità. Il problema è il metro con cui si misura la qualità di una traduzione tecnica.

Il mio parere è che, molto spesso, una traduzione è tanto più valida quanto poco è completa.

Pochi giorni fa stavo rileggendo alcune pagine di un volume sui sistemi operativi, nel quale il termine inglese HANDLE viene tradotto con MANIGLIA. Ora, non metto in dubbio che in italiano "handle" significhi "maniglia". Semplicemente mi sembrava poco naturale parlare di "maniglia di un semaforo" ... allora perchè non dire che con tale maniglia i "fili" possono sincronizzare l'accesso ad una risorsa !?!! (filo = thread)

Non è questione di fare i fighi o tanto meno di essere esterofili.

Solo credo che lo scopo della lettura di un volume tecnico sia quello di apprendere. Ed ognuno deve ricercare il mezzo (anche la lingua) che gli facilita l'apprendimento.

Da un lato, non essendo la mia lingua madre, sicuramente leggere in inglese comporta un ulteriore livello di "filtro" (la traduzione) e mi rende meno immediato l'assorbimento delle nozioni. Dall'altro, pero, si fa fatica a ri-tradurre tutti i termini come "maniglia" nel loro corrispettivo originale !

Voi cosa ne pensate ?

powered by IMHO

Ho letto con interesse questo post di Andrea Boschin relativo alle dimensioni in memoria delle struct.
Trovo sicuramente valide le considerazioni di Andrea: un risparmio di 4 byte è nulla sul singolo elemento, ma può assumere proporzioni ben maggiori su collection ben .. nutrite.
Ciò che, a mio parere, è ancora più importante è che una scarsa attenzione al layout di una struct può determinare effetti ben peggiori che alcuni mega di memoria virtuale occupata.
Mi riferisco alle situazioni di interoperabilità con applicazioni non gestite.

Immaginate di dover accedere ad un'area di memoria non gestita tramite la seguente struttura:

struct MyStruct {
  UInt16 wordValue;
  UInt32 dwordValue;
}

La classe System.Runtime.InteropServices.Marshal offre diversi metodi statici che consentono l'interazione con un ambiente non gestito.
Tra questi ci viene in aiuto, nel nostro esempio, il metodo PtrToStructure, che accetta un IntPtr e un'istanza di Type (il tipo che vogliamo marshalare) e ritorna un Object "castabile" al nostro oggetto target.
Per copiare i dati dall'area non gestita a quella gestita, la classe Marshal va a controllare le dimensioni, in byte, del tipo destinazione, e tale numero di byte viene copiato all'interno dello heap gestito.

Nel nostro caso, quanti byte occupa la struttura MyStruct ?
6, senza ombra di dubbio ! Peccato che, per ragioni di padding (rimando nuovamente al post di Andrea e all'articolo su MSDN che Andrea linka), la struttura occupa 8 byte.
Inutile dire che le conseguenze non sono esattamente piacevoli.

Il primo consiglio, in situazioni del genere, è di esplicitare il layout di una struct tramite l'attributo System.Runtime.InteropServices.StructLayoutAttribute, specificando il tipo di layout esplicito.
In tal modo, la definizione di MyStruct diventa:

[StructLayout (LayoutKind.Explicit)]
struct MyStruct {
  UInt16 wordValue;
  UInt32 dwordValue;
}

Questo codice non compila, non ancora, per lo meno. Infatti, quando viene richiesto un layout esplicito per un tipo, occorre indicare al runtime gli offset dei singoli campi.
Niente di più facile.
Riscriviamo MyStruct:

[StructLayout (LayoutKind.Explicit)]
struct MyStruct {
  [FieldOffset (0)]
  UInt16 wordValue;
  [FieldOffset (2)]
  UInt32 dwordValue;
}

In questo modo, il campo dwordValue viene letto dalla posizione di memoria immediatamente contigua a wordValue, senza che vengano inseriti i 2 byte di padding.

Quindi, finalmente, MyStruct occupa .... 8 byte !

Ma come ?!?
Beh, in effetti non abbiamo fatto altro che "spostare" i due byte di padding in fondo alla struttura !
Se controlliamo le dimensioni di MyStruct (tramite Marshal.SizeOf (typeof (MyStruct))) il valore che ci viene ritornato è 8.

In un errore di questo tipo sono incappato alcuni mesi fa: dovevo accedere ad un MemoryMappedFile da un'applicazione .NET. Avevo a disposizione una classe a cui dovevo passare semplicemente l'offset di un dato a partire dal suo IntPtr di base.
La mia struttura (era un po' più lunga di MyStruct, ovviamente, ma poco cambia) affermava di essere grossa 124 byte (se non ricordo male), mentre in realtà i byte erano 123.
Dovendo accedere ad un array di strutture, non facevo altro che richiamare la funzione di accesso passando un valore intero, incrementato all'interno di un ciclo di Marshal.SizeOf(typeof (MyOtherStruct)) byte, cioè 124.
Verso la fine del ciclo, immancabile giungeva un'eccezione Win32: stavo leggendo dove non dovevo !

E allora ?

La soluzione è stata semplice: l'attributo StructLayout accetta un parametro Size, tramite il quale si può specificare la dimensione reale della struttura.
Impostato quello, tutto è filato liscio

... beh, sino al bug successivo, ma questa è un'altra storia !

powered by IMHO