j'aimerais que quelqu'un m'aide pour resoudre cette enonce car je ne comprend pas comment le faire.
je sais deja faire une GESTION DE MEMBRES DANS UN TABLEAU DE STRUCTURES.
voici l'énonce:
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.
• Un menu permettra à l’utilisateur de choisir l’action qu’il souhaite réaliser : ◦ ajout d’un nouvel enregistrement (ajout dans l’index et dans le fichier), ◦ modification d’un enregistrement existant (excepté le numéro et le nom) sur base du numéro, ◦ suppression d’un enregistrement sur base du numéro (le numéro est mis à "-1" dans le fichier et l'index est mis à jour), ◦ affichage des données d’un (ou plusieurs) enregistrement(s) recherché(s) sur base du nom, ◦ affichage des données de tous les enregistrements (triés par noms)
merci .
- Edité par EmmanuelMbaya 16 avril 2022 à 19:19:00
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
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
Le Tout est souvent plus grand que la somme de ses parties.
-> 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
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
Le Tout est souvent plus grand que la somme de ses parties.
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)
Oui intervertir la dernière case rempli du tableau avec la case qui vient d'etre supprimer en l'ayant vider avant et ça devrait le faire. Mais tout dépend de comment lui veux l'implémenter tant qu'il a une idée de la consigne. D'ailleurs 4h mon cerveau n'est plus apte à la réflexion :-) il y a peut être meilleur solution
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
un fichier avec indexe
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
yasakani no magatama
Le Tout est souvent plus grand que la somme de ses parties.
yasakani no magatama
Le Tout est souvent plus grand que la somme de ses parties.
yasakani no magatama
Le Tout est souvent plus grand que la somme de ses parties.
yasakani no magatama
Le Tout est souvent plus grand que la somme de ses parties.