---

Hola gente. Tengo un problema de lo más "loco". A ver si ustedes tienen alguna idea.

Estaba haciendo una clase que implementa un buffer. Uno le pasa alguna variable y el buffer descompone la variable en bytes y la almacena en su propio espacio de almacenamiento para después poder escribirla en disco.

De repente empecé a encontrar alguna cosa mal guardada y al investigar me encontré con esto:

Supongamos que tengo:

type r= record
b: byte;
i: longword;
end;

var reg: r;

Y hago algo como Buffer.Escribir(reg,SizeOf(reg));

El buffer va a usar un ^byte que toma el valor de @reg y va a ir recorriendo los bytes independientes (incrementando con Inc)hasta recorrer la cantidad indicada por SizeOf.

Pero, resulta que SizeOf ¡devuelve 8!

Entonces el buffer se manda flor de "macana" al tratar de recorrer los bytes, ya que trata de recorrer 8 bytes cuando tendría que recorrer 5. Lo más increíble es que ¡encuentra los 8 bytes! Entre el primer byte (correspondiente al campo b) y el "segundo" (correspondiente al campo i) encuentra 3 bytes que no se sabe de dónde salieron.

Por ejemplo, siendo:

b=3
i=15

Aparecen los bytes:

03,F5,12,00,0F,00,00,00

Los primeros 4 bytes se deben al campo b (¡de 8 bits!), que sólo debería ser 03. Los bytes F5,12,00 parecen ser aleatorios, como si fueran basura.

Después están los 0F,00,00,00 del campo i, que están bien.

Si yo, deliberadamente, hago Buffer.Escribir(reg,5); Entonces el bufer escribe:

03,F5,12,00,0F

Es decir, sigue recibiendo una variable de 8 bytes.

Con cualquier tipo de dato menor que 32 bits, simplemente devuelve 8, como si el campo fuera de 32 bits...

Si cambio b:byte, por algo como b:string[10], SizeOf devuelve 16, que tampoco está bien.

Los SizeOf de variables independientes (que no están en un registro) son devueltos correctamente. El SizeOf(reg.b) es 1, efectivamente correcto. Incluso usándolo sobre un arreglo, devuelve correctamente su tamaño.

Tanto SizeOf sobre el tipo de dato o sobre la variable funcionan igual.

Algo más increíble todavía, es que cuando leo de disco de nuevo en el buffer y finalmente en la variable, todo queda perfecto. Ahora, ¿Cómo no sobreescribo memoria? Un misterio.

En la ayuda dice que suele usarse word o double-word para almacenar números en tipos de datos complejos, aunque esto no pasa con los arreglos... En fn.

Algo de locos.

¿Ideas? Sí, ya sé, que me tire de un puente. Y que abajo del puente haya una cama de clavos bien afilados, oxidados, e impregnados con veneno de cobra real... y también electrificados. Pero no es una opción :( Aunque lo haría si pudiera conseguir el veneno...

Saludos y gracias.

PD: Por si sirve de algo, es un Delphi 7 corriendo sobre WinXP SP2 en una Pentium IV. 

---

Hola Delfos : {y a todo el mundo, que hace tiempo que no me paso por aquí}

Bueno, tu problema.. es menos grave de lo que piensas xD. a ver si consigo explicarme bien {y si no estoy en lo correcto, que alguien me corrija}. Para empezar, no es un SizeOf loco, todo esto va de memoria y optimización. Delphi, en un afán de acelerar el acceso a los datos, guarda en memoria los records de la manera que "mejor le viene", esto significa, que, por ejemplo, si tenemos esto:

type 
    MyRec = record
      Variable1: Byte;
      Variable2: DWord;
    end;

Delphi alineará este "record" como a él mejor le parezca para después, acceder a los datos más rápidamente.
En este caso,

SizeOf(MyRec)

devolverá 8, lo cual no significa que "Variable1" ocupe 4 bytes, si no que los ha alineado de forma que el tamaño de trabajo es de 8 bytes.

Ahora bien.. ¿como arreglar este "fallo"? Bueno, si no quieres que delphi haga de las suyas en esta clase de cosas (y con hacer de las suyas me refiero a intentar agilizar su trabajo), la solución es simple se llama "packed".. y se implementa tal que así:

type
  MyRec = packed record
    S: Byte;
    S1: DWord;
  end;

Si ahora haces un

SizeOf(MyRec)

verás que en este caso, si que da lo que debería dar si los datos están alineados tal y como los has puesto, que es 5 bytes.

Espero que esto te haya solucionado el problema.

Un Saludo AitorC

P.S.: Si no me he explicado muy bien.. y quieres q lo explique mejor {lo he puesto todo muy por encima}, solo tines q pedirlo