Nuńo Martínez:
Cita:
- Si usamos Turbo C/C++ 1.1 el "archivo.dat" es de dos octetos de longitud y su valor es "0xEC12".
- Si usamos MinGW32 el "archivo.dat" es de cuatro octetos de longitud y su valor es "0xEC120000".
- Si usamos un compilador para Motorola de 16 bit apuesto el pellejo a que el archivo es de dos octetos de longitud y que su valor es "0x12EC".
- Y si el compilador es para PowerPC dudo mucho que el archivo tenga una longitud distinta a 4 octetos y que su contenido difiera de "0x000012EC".
|
Again....
Yo mismo:
Cita:
|
si vas a usar enteros largos uses long int o long, si son cortos uses short int o short, no declares int solamente, puesto q si tu archivo llega a ser abierto en una plataforma cuyo direccionamiento es mayor o menor...ahi si tendrěas cierto inconveniente....del resto......se encarga el sizeof
|
y again again
Cita:
...este es el tema de la codificaciňn como little/big endian, pero eso no es motivo pa morir...si se usa otras funciones....no habrěa q validar de todos modos?
Si sabes q tu aplicaciňn ha de correr en otras plataformas...lo lňgico fuese q validaras en donde estŕ parado, mira esto http://www.thescripts.com/forum/thread520538.html
|
En cuanto a la cantidad de octetos creo q
ya qedo aclarado, ahora....el orden de los octetos es + importante...eso depende de la plataforma/procesador y en el link ya hay una forma de como saberlo....al fin y al cabo habra q usar fwrite/fread independientemente de la plataforma/compilador.....si tienes registros de 10 o mas campos te pondrŕs a escribir fputs, fputc, putw, etc, etc cada vez q hayas de escribir y sus anŕlogas cada vez q hayas de leer?...seria mas codigo y mas tiempo
. Es cuestiňn de no hacer programas de forma empěrica asumiendo muchas variables sino de vez en cuando validar el comportamiento de nuestro exe de acuerdo al lugar donde se encuentre...