Discussion :

[Antoine.V]

Bonjour,

Je d�bute un peu en C et C++ et j'aimerais savoir les m�thodes qu'il �xiste pour supprimer un enregistrement de type struct dans un fichier.
Je travaille sur des terminaux de type bancaire donc l'espace m�moire est relativement limit�. Donc j'oublie la m�thode qui r��crit un nouveau fichier avec comme condition de ne pas y metre l'enregistrement � effacer et puis effacer l'ancien fichier.

Je connais la m�thode d'indexation, mais ce serait r��crire beaucoup de modules du terminal, j'aimerais donc ne pas y avoir recours.

Merci beaucoup.

[DaZumba]

Tu peux faire un fopen() en mode "r+" (ecriture / lecture) et jouer avec fseek(), mais tu vas detruire le fichier (un bug est vite arrive). L'algorithme a developper est bien plus complexe qu'un simple lecture/filtrage/ecriture.

[Emmanuel Delahaye]

Je d�bute un peu en C et C++ et j'aimerais savoir les m�thodes qu'il �xiste pour supprimer un enregistrement de type struct dans un fichier.

Si l'acc�s aux enregistrements est simple (taille fixe, rep�re...) et que tu as pr�vu un champ pour �a, tu peux marquer l'enregistrement 'supprim�', mais �a ne r�duira pas la taille du fichier... (Utilisation du mode "r+", il vaut mieux savoir ce qu'on fait...)

Je travaille sur des terminaux de type bancaire donc l'espace m�moire est relativement limit�. Donc j'oublie la m�thode qui r��crit un nouveau fichier avec comme condition de ne pas y metre l'enregistrement � effacer et puis effacer l'ancien fichier.

Je ne comprend pas ton probl�me de m�moire. La m�thode lecture/filtrage/ecriture consomme tr�s peu de m�moire (un enregistrement). Par contre, pendant le moment du traitement on a besoin de 2 fois la taille du fichier sur le disque, mais c'est temporaire... Quand c'est termin�, on peut effacer l'ancien fichier (si on ne veut pas garder un 'backup' de la version N-1...)

C'est une m�thode �prouv�e et surtout tr�s fiable. Ok, il faut un peu de place sur le disque...

[Antoine.V]

Je ne comprend pas ton probl�me de m�moire. La m�thode lecture/filtrage/ecriture consomme tr�s peu de m�moire (un enregistrement). Par contre, pendant le moment du traitement on a besoin de 2 fois la taille du fichier sur le disque, mais c'est temporaire... Quand c'est termin�, on peut effacer l'ancien fichier (si on ne veut pas garder un 'backup de la version N-1...)

C'est une m�thode �prouv�e et surtout tr�s fiable. Ok, il faut un peu de place sur le disque...

Car la m�moire d�di�e du terminal fait 2 m�ga octets. Ce m�me fichier peut varier entre 0 et 2 m�ga octets. il suffit que le fichier fasse 1 Mega et 1 octet et c'est foutu...

Oui j'avais pens� � metre un flag pour signaler que l'enregistrement n'est plus valide et lors d'un prochain ajout d'enregistrement, le m�tre � la place d'un enregistrement signal� non valide par le flag. Ca m'embetait un peu car c'est rajouter un octet � chaque enregistrement dans un fichier qui doit �tre le plus petit possible mais c'est la solution qui me semble la plus simple pour le moment.

[Emmanuel Delahaye]

Car la m�moire d�di�e du terminal fait 2 m�ga octets.

Je ne comprends pas. Tu parles de m�moire centrale ou de m�moire sur disque ?

Ce m�me fichier peut varier entre 0 et 2 m�ga octets. il suffit que le fichier fasse 1 Mega et 1 octet et c'est foutu...

Et ce n'est pas modifiable ? L'administrateur est manchot ou quoi ?

Oui j'avais pens� � metre un flag pour signaler que l'enregistrement n'est plus valide et lors d'un prochain ajout d'enregistrement, le m�tre � la place d'un enregistrement signal� non valide par le flag. Ca m'embetait un peu car c'est rajouter un octet � chaque enregistrement dans un fichier qui doit �tre le plus petit possible mais c'est la solution qui me semble la plus simple pour le moment.

C'est jouable, mais c'est dangereux (pas de sauvegarde, une fausse manip et le fichier est d�truit), et il faut que les enregistrements aient une taille fixe... (ce qui est contraire au principe �nonc� "un fichier qui doit �tre le plus petit possible"). Bref, je sens comme un probl�me majeur de conception ou de compr�hension dans cette affaire...

[Antoine.V]

Je ne comprends pas. Tu parles de m�moire centrale ou de m�moire sur disque ?

Et ce n'est pas modifiable ? L'administrateur est manchot ou quoi ?

Non, je me suis mal fait comprendre , c'est un terminal de type bancaire, ce n'est pas un pc. C'est un lecteur de carte � puce �volu� programmable en C++ via un compilateur propri�taire. Il contient une m�moire Flash o� sont stock� l'application et l'OS et une m�moir� SRAM de 2 m�ga o� est stock� le fichier et qui sert de m�moire de travail. Cette valeur est inchangeable. C'est pour cela que le fichier doit etre le plus petit possible et encore moins en faire un double puis �ffacer le d�suet. Au moment du d�doublage, la m�moire risque d'�tre vite satur�e.

[Emmanuel Delahaye]

Non, je me suis mal fait comprendre , c'est un terminal de type bancaire, ce n'est pas un pc. C'est un lecteur de carte � puce �volu� programmable en C++ via un compilateur propri�taire. Il contient une m�moire Flash o� sont stock� l'application et l'OS et une m�moir� SRAM de 2 m�ga o� est stock� le fichier et qui sert de m�moire de travail. Cette valeur est inchangeable. C'est pour cela que le fichier doit etre le plus petit possible et encore moins en faire un double puis �ffacer le d�suet. Au moment du d�doublage, la m�moire risque d'�tre vite satur�e.

Il fallait peut �tre y penser avant ? On ne ne peut pas g�rer un fichier de taille N si on a pas 2xN libre. C'est pas un scoop. Probl�me de conception... La r�alisation ne peut pas regler les probl�mes de conception. Aller secouer les puces de l'ing�nieur qui a pondu cette merveille...

[DaZumba]

Car la m�moire d�di�e du terminal fait 2 m�ga octets. Ce m�me fichier peut varier entre 0 et 2 m�ga octets. il suffit que le fichier fasse 1 Mega et 1 octet et c'est foutu...

Mais tu n'as pas a charger la totalite du fichier en memoire. Il te suffis de boucler sur les enregistrements et les lire un par un, modifier puis ecrire.