6. UN FICHER AVEC INDEX

• Créez une application qui va permettre de gérer des enregistrements constitués des champs suivants : un numéro (unique, calculé par le programme), un nom, un prénom, une adresse, un code postal et une localité. Ces enregistrements seront sauvés dans un fichier sur disque. Ce fichier aura la particularité d’être "bidonné". Cela signifie qu’il sera initialisé au départ de manière à contenir 15 structures vides. On supposera que l’application ne gérera jamais plus de 15 enregistrements

• Le fichier sera un fichier indexé, l’index étant constitué en mémoire au démarrage de l’application. L’index contient le numéro, le nom et l’offset dans le fichier de l’enregistrement correspondant. L'index chaîne à la fois les enregistrements occupés (par noms) et libres, donc si le fichier ne contient aucun enregistrement, un lien sera quand même créé entre l’index et les enregistrements dans le fichier ce qui permettra de trouver rapidement un emplacement libre lors de l’ajout d’un élément.

-
Edité par EmmanuelMbaya 16 avril 2022 à 19:19:00

Bonjour ,

ton sujet veux en bref que tu travailles avec les octets  par exemple

ta structure

struct{

char name[30];

char f_name[30];

char postal_code[7];

}Member;

Avec une structure comme ça tu sais que chaque item de ton fichier fais 67 octet un char prenant 1 octet

donc si tu en as deux a la suite dans un fichier

la premiere aura l'offset 0 la deuxieme qui est juste après aura l'offset 67

avec une lecture du style

Member member_struct;

fread(&member_struct,67,sizeof(Member),1);

Edition: la syntaxe du fread est fausse pour l'exemple ce serait

fread(&member_struct, sizeof(Member), 1,ton_fichier);

Si on te dit qu'elle ne gèrera au maximum que 15 enregistrement ca veux dire que tu peux deja initialiser un tableau de ta structure de taille 15 car le fichier contient dans tous les cas (vide ou rempli) 15 enregistrement

Et ton index servira à gérer le tout

Ca sera quelque chose au tout début de ton fichier qui comme le sujet le dit donnera l'offset de la première structure libre par exemple

-
Edité par zvheer 17 avril 2022 à 13:46:05

Dans le cas présent le problème ne se pose pas mais il faut faire attention aux alignements.
Il vaut mieux écrire et lire sizeof(ta_structure) octets.
@zvheer:
Est-ce que tu suggères d'écrire 15 ofsets au début du fichier ou un seul?
S'il y a 2 enregistrements vides, comment je le saurai?
On peut facilement calculer la position en ofset de chaque enregistrement. Ce dont on a besoin de savoir c'est si un enregistrement est vide.
Pourquoi pas 15 octets au début avec un code pour rempli et un code pour vide?

Il faudra utiliser fseek() pour se positionner sur le bon code et écrire un octet.

Puis se positionner sur le bloc de l'enregistrement pour l'écrire.

> • Créez une application qui va permettre de gérer des enregistrements constitués des champs suivants : un numéro (unique, calculé par le programme)
Est-ce que ce numéro sera en caractères? Unique par rapport à quoi? Les numéros 1 à 15 ne sont-ils pas uniques?
Je te suggère d'attendre pour afficher trié par nom. C'est peut-être plus compliqué.
Affiches en ordre de position au début pour mettre au point ta foncion d'affichage.

edit:
Si je relis l'énoncé du problème, il n'est dit nulle part que l'index doit être écrit dans le fichier.
En supposant que l'adresse et la localité prennent moins de 100 caractères chacune, on peut dire que chaque enregistrement fera au maximum 300 caractères
Donc, le fichier fera au maximum 4500 caractères. Il pourrait être écrit et lu avec une seule lecture.
L'index est construit en mémoire d'après les données lues.
Il faudrait savoir si le but de l'exercice est de gérer des enregistrements ou de faire de la réécriture sur disque.

-
Edité par PierrotLeFou 17 avril 2022 à 3:29:53

-> Est-ce que tu suggères d'écrire 15 ofsets au début du fichier ou un seul?S'il y a 2 enregistrements vides, comment je le saurai?On peut facilement calculer la position en ofset de chaque enregistrement. Ce dont on a besoin de savoir c'est si un enregistrement est vide.Pourquoi pas 15 octets au début avec un code pour rempli et un code pour vide?

je ne lui ai rien suggéré de réel mais son soucis était au niveau de compréhension de la consigne et pour moi c'est l'offset... qui le dérangeait,d'où les exemples donnés.

Mais si l'on prend sa consigne a la lettre le fichier doit etre remplis dans tous les cas donc etant donné que c'est 15 enregistrements au maximum un seul octet servira a donner l'offset du premier enregistrement vide.

Car si les enregistrements se suivent il les remplira dans l'ordre dans la consigne he n'ai vu aucune indication l'interdisant.il lui suffit donc juste de donner l'offset de fin du dernier enregistrement remplis. Si l'offset est a 15 alors le fichier est plein et ne peut qu'être modifier

Étant donné que ce n'est pas la seule donnée attendu dans son en tête c'est a lui de voir comment il souhaite gérer ça d'où les exemples pour se représenter la chose 

-
Edité par zvheer 17 avril 2022 à 3:21:29

S'il détruit plus d'un enregistrement, il y aura des trous.

Je suppose une fermeture du fichier et un nouvel appel du programme.
S'il n'a que l'offset du premier enregistrement vide, comment saura-t-il où trouver le suivant?
PS. Je n'ai pas rafraichi la page avant de poster ma modification.

-
Edité par PierrotLeFou 17 avril 2022 à 3:41:20

de ma maniere de penser actuel ce fichier sera un fichier de taille fixe. 

Son en tete imaginons 15 octets au pif

1 pour l'offset du premier enregistrement vide le reste pour ce qu'il a a jouter

disons que ca structure membre ferait 10 octets.

donc 15 + (10 * 15)

a sa lecture de fichier il lirait ses 15 premiers octets

il sait qu'après ça sa suite d'enregistrement commence 

donc un fread de sizeof(enregistrement) 15 fois lui remplirai son tableau.

S'il veut aller directement a l'enregistrement vide

15 + ( 10 * offset) lui donnerait cet emplacement

offset en serait pas réellement le nombre d'octet avant mais bien le numero d'enregistrement d'ou taille d'en tête + 10 * offset

.S'il n'a que l'offset du premier enregistrement vide, comment saura-t-il où trouver le suivant

A l'écriture du fichier il a forcément 15 enregistrement ( qui sont vide au premier lancement sur ce fichier) 

donc l'offset sera 0

il ecrira donc sur le premier enregistrement 

offset++

donc a aucun moment il n'a besoin de connaître le suivant etant donné qu'il les ecrira dans l'ordre. 

Mais sa implique qu'a la suppression il les réorganise dans cet ordre ( s'il fait une ecriture direct de son tableau de structure il n'aura pas ce problème) 

-
Edité par zvheer 17 avril 2022 à 3:55:35

-
Edité par zvheer 17 avril 2022 à 4:10:17

Interchanger le dernier rempli avec celui qui a été supprimé est parfait ...

Il faut juste reculer l'ofset vers le premier trou.
Je ne trouve pas la consigne si claire après tout.

-
Edité par PierrotLeFou 17 avril 2022 à 4:41:40

EmmanuelMbaya a écrit:

 ◦ suppression d’un enregistrement sur base du numéro (le numéro est mis à "-1" dans le fichier et l'index est mis à jour), 

Un enregistrement vide à donc un N° à -1 

Oui, j'avais compris cela aussi. Le numéro est un identifiant unique pour une personne, et une place libérée sur le fichier suite au retrait d'un enregistrement consiste juste à marquer l'enregistrement en écrasant son identifiant stocké dans le fichier en le remplaçant par -1 (et à gérer le changement en mémoire vive et dans l'index en mémoire vive).

Si c'est une écriture sur le disque à chaque changement, on attend peut-être un format binaire des données, plutôt qu'un format texte qui nécessiterait une réécriture complète à chaque modification. Cela pose plusieurs problèmes de portabilité, mais comme c'est un exercice, peut-être que le but de l'exercice est juste de montrer qu'on sait utiliser fwrite(), fread(), fseek(), et qu'on ne doit pas gérer une vraie sérialisation...

-
Edité par Dlks 19 avril 2022 à 13:17:58