bonjour , je suis rendu au chapitre sur les fichiers du cours sur le langage c et je n'arrive pas a ouvrir un fichier txt ,je vous remercie d'avance de votre aide, voici mon code :
il n'ya pas d'éxécutable dans le dossier de mon projet
Donc il faut que tu cherches dans quel dossier est situé l'exécutable. Peut-être dans "bin" ? À toi de le trouver. (Moi je ne sais pas, je n'utilise pas d'IDE.)
Herox Codeur a écrit:
zoup : déja essayé et cela ne marche pas
Du coup il y a deux possibilités : A − zoup dit n'importe quoi ; B − tu t'y es mal pris. Tu as droit au 50/50...
(Si tu n'as pas réussi avec le chemin absolu, il serait plus constructif que tu montres comment tu t'y es pris. Par exemple si tu es sous Windows il est possible que tu n'aies pas écrit correctement les séparateurs '\', c'est une erreur classique. En montrant comment tu as fait, tu as des chances d'obtenir de l'aide.)
il étais effectivement dans bin , j'ai donc mis le fichier test.txt dedans avec l'executable et j'ai mis ça comme chemin absolu : C:\\Users\\herox\\Documents\\Langage C\\fichier\\bin\\Debug\\test.txt
mais a la compilation sa affiche jutse une console noire vide avec "process returned 0"
donc ni le contenu du fichier texte ni un moyen d'ecrire dedans
Ton code ne demande pas de lire le fichier et d'afficher ce qu'il a lu. Il affiche juste "gg" si le fichier a été ouvert (fichier que tu oublies d'ailleurs de fermer) ou "erreur". En C, il faut tout faire: ce n'est pas parce que tu ouvres un fichier que son contenu s'affiche à l'écran.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Ton code ne demande pas de lire le fichier et d'afficher ce qu'il a lu. Il affiche juste "gg" si le fichier a été ouvert (fichier que tu oublies d'ailleurs de fermer) ou "erreur". En C, il faut tout faire: ce n'est pas parce que tu ouvres un fichier que son contenu s'affiche à l'écran.
Je crois que le but est juste de vérifier si le fichier est bien ouvert. Herox Codeur s'attend donc à ce que le programme affiche "gg". Mais là ça affiche "erreur", preuve que l'ouverture ne s'est pas faite.
PierrotLeFou : Herox Codeur a déjà répondu : l'exécutable est dans bin\Debug et il a placé "test.txt" dedans. Si "test.txt" et l'exécutable sont bien tous les deux dans le même répertoire, ça doit marcher !
Herox Codeur a écrit:
j'ai mis ça comme chemin absolu : C:\\Users\\herox\\Documents\\Langage C\\fichier\\bin\\Debug\\test.txt
Ce serait mieux de nous montrer le code qui contient ce chemin absolu. Ça se trouve, tu n'as pas écrit tout à fait ça (faute de frappe ou quelque chose de ce genre − il faut bien qu'il y ait une raison au fait que ça ne marche pas...).
Et avec ça tu obtiens bien "erreur" (comme tu l'indiques dans ton premier message), ou bien rien du tout (comme tu l'indiquais il y a une heure) ?
Dans l'explorateur, quand tu tapes "C:\Users\herox\Documents\Langage C\fichier\bin\Debug" dans la ligne du haut, ça mène bien à un répertoire qui existe et qui contient "test.txt" et l'exécutable ? Comment l'as-tu contrôle ? (Oui, c'est une question bête, mais je n'ai pas beaucoup d'idées...)
Et si tu remplaces les \\ par des /, ça donne quoi ? (Je me demande si je n'ai pas lu quelque part que certaine compilateurs C utilisent les / à la place des \).
Cela fonctionne indifféremment avec \\ ou / pour Windows au moins.
Dans un test du programme dans l'environnement code::blocks, le chemin est relatif au dossier contenant le projet.cbp, du moins ça a toujours été le cas chez moi.
C'est lors de la création du release et du lancement de celui-ci en stand alone que les chemins sont relatif au projet.exe.
Ce que je vois dans le log de ton screen c'est que tu as une erreur d'exécution de ton programme que tu ne peux pas voir à l'exécution puisque ton main ne retourne rien, très certainement lié à une redéfinition de la fonction fopen. Donc commence par virer la ligne 4 : fopen est déjà définie par l'inclusion de stdio.h
Le chemin courant de l'exe est également donné en argument dans argv[0] lorsque l'on utilise les arguments du main. Il suffit de retrancher le nom de l'exécutable pour avoir le dossier.
Tu as laissé la ligne 4 malgré la remarque de drx. Pense à rectifier...
Pour lire et écrire dans un fichier, une façon de voir les choses est d'utiliser 'printf' et 'scanf' comme on le fait en console, mais avec leurs versions pour fichier : 'fprintf' et 'fscanf'.
Exemple :
fichier=fopen("C:\\Users\\herox\\Documents\\Langage C\\fichier\\bin\\Debug\\test.txt","r+");
// Maintenant que le fichier est ouvert en lecture, on peut le lire avec 'scanf'
// Supposons que ce fichier contienne deux nombres entiers à la suite
int n1, n2 ;
fscanf(fichier, "%d %d", &n1, &n2) ; // en console on aurait écrit : scanf("%d %d", &n1, &n2) ;
Et c'est pareil avec un fichier ouvert en écriture : on utilise 'fprtinf' qui est identique à 'printf' à part qu'il faut indiquer 'fichier' en premier argument.
robun , le code que tu m'a donné je l'ai mis et j'ai bien viré la ligne 4 mais je n'obitens pas l'affichage du fichier mais juste une console noire avec rien d'ecrit puis process returned (une adresse memoire genre 0x36262828281)
mais cela ne m'affiche pas le cotenu du fichier test.txt (que j'avais au préalablement remplis de seulement 2 chiffre)
L'idéal serait d'avoir sous les yeux le code source en question.
pronlème avec l'ouverture des fichiers
× 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.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Bonhomme !! | Jeu de plateforme : Prototype.
Le Tout est souvent plus grand que la somme de ses parties.
Bonhomme !! | Jeu de plateforme : Prototype.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.