Manejo de Archivos con C++ Builder

[OSKR]

Gracias a Dios alguien comenta esto....
Si es recomendable...no hay problema alguno
Ñuño Martínez:

igual los registros ni los datos en memoria

falso.....el fwrite y el fread no saben q estan leyendo....solo saben q tienen q extraer cierta cantidad de bytes (sizeof(struct Registro)) en bloqes de n (3º paràmetro) del apuntador al descriptor de archivo señalado por el puntero (pf), usar fgetc y fputc es lo mismo....solo q implicara mas lìneas y mas validaciones para formar los datos q necesitamos...por eso no necesariamente leemos registros (eso es facinante.......LIBERTAD !!!!)

por ejemplo no lo hacen igual Turbo C (que es de 16 bit) y Builder C++ (que es de 32 bit)

Negativo procedimiento...he sido preparador de asignaturas como Estructura de Datos en las cuales he usado C(++) hasta decir BASTA (y en 1 una u otra ocasion java...) y nunk he tenido ese problema...claro...hay q tener en cuenta q 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.

Por otro lado, si se cambia de microprocesador el orden de los octetos pueden variar, como es el caso de portar porgramas de Motorola (Mac) a Intel (PC).

De eso hasta el momento creo q solo java se encarga de hacer eso transparente...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 ...he ahì un ejemplisho de como saberlo, ademàs debes saber con q Endian trabaja el procesador