Manejo de Archivos con C++ Builder

[Tapax]

Hola Foro,
Estoy de manejar archivos con c++ builder.
Bueno en Delphi se puede manejar un archivo con registros, por ejemplo:

      Tproducto= record
     codigo:string[5];
     articulo:string[45];
     P_compra:real;
     P_venta:real;
     stock:integer;
    end;
Tarchivo= File of Tproducto;

De manera que cuando quiero almacenar, le mando un registro y hago esto
Código Delphi [-] Procedure almacena(Preg:TProducto;pos:integer); begin assignfile(aArchi,'producto.dat'); reset(aArchi); seek(aArchi,pos); write(aArchi,preg); closefile(aArchi); end;


Se puede hacer lo mismo en c++ builder???
Agradezco de antemano las respuestas

[Casimiro Notevi]

Sí, claro, es practicamente igual, tan sólo deberás respetar la sintaxis del lenguaje.

[nemesio]

Hola

Si quieres algunas rutinas de archivos, puedes consultar en www.lawebdelprogramador.com o alguna otra de tu preferencia. Yo encontré a simple búsqueda este http://www.lawebdelprogramador.com/c...xto=C/Visual+C, pero hay muchos más.


Suerte.

[OSKR]

Hello, dias sin pasar por aqi, Tapax... aqi en C no relacionas un archivo binario con una estructura o registro....solo abres el archivo y luego decides como y q leeràs de el..
La estructura:

struct registro
{ char codigo[5][Long_Codigo]; //creo yo qs un arreglo d cadenas
   char articulo[45][Long_Articulo];
   float P_compra;
   float P_venta;
   int   stock;
};
//....
.
.
.

la variables serìa:

registro reg;

el archivo puedes abrirlo como:

FILE *pf=fopen("nombre_archivo","rb+");

y puedes leer:

fseek(pf, 0, 0);
fwrite(&reg, sizeof(struct Registro), 1, pf);

y asi.... tendràs q ver bièn los paràmetros de cada funciòn y los errores q pudieran arrojar usando la variable global " errno "....Haz tus pruebas y pregunta cualqier cosa q si puedo aparecerme pronto respondo

[Ñuño Martínez]

y puedes leer:

fseek(pf, 0, 0);
 fwrite(&reg, sizeof(struct Registro), 1, pf);

No es recomendable usar fwrite ni fread para leer o escribir datos binarios en archivos de disco, de hecho sólo se mantienen por compatibilidad (en algún sitio leí que quisieron eliminarlas de la norma "C99"). En lugar de eso hay que utilizar fgetc y fputc.

Las razones por lo que no es recomendable usar fwrite ni fread son principalmente dos (en realidad una sola). Por un lado no todos los compiladores alinéan igual los registros ni los datos en memoria, por ejemplo no lo hacen igual Turbo C (que es de 16 bit) y Builder C++ (que es de 32 bit). 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).

[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

[Ñuño Martínez]

Pongo un ejemplo:

#include <stdio.h>
#include <stdlib.h>

int ValorEntero = 0x12EC;

int main (void)
{
  FILE *Archivo = NULL;

  if (!(Archivo = fopen ("archivo.dat", "w"))
    return EXIT_FAILURE;
  if (fwrite (&ValorEntero, sizeof (ValorEntero), 1, Archivo) != 1)
    return EXIT_FAILURE;
  fclose (Archivo);
  return EXIT_SUCCESS;
}

Vale.

• 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".

[OSKR]

Nuño Martínez:

• 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:

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

...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...

[Tapax]

Wow, muuuchas gracias por las respuestas, muy muy muy interesantes.
Ahora si he aprendido a manejar archivos
Graciassss