Ça ne doit pas être facile de "vulgariser" suffisamment pour qu'un débutant puisse comprendre, mais là je suis vraiment largué.
En tous cas pour répondre, ce que je constate, c'est que l'algorithme de tri du tableau que j'avais trouvé sur le net avait moins de ligne de code que celui pour mettre le minimum au début. Et je trouvais juste ça étonnant, mais ça l'est peut-être pas pour vous.
On t'a peut-être induit en erreur. Il faut cesser de penser en termes de nombres de lignes. Il faut plutôt essayer de comprendre ce que tu fais et faire fonctionner correctement ton codde. Après seulement, tu pourras te demander comment améliorer ton code et le réduire si possible.
Le Tout est souvent plus grand que la somme de ses parties.
On t'a peut-être induit en erreur. Il faut cesser de penser en termes de nombres de lignes. Il faut plutôt essayer de comprendre ce que tu fais et faire fonctionner correctement ton codde. Après seulement, tu pourras te demander comment améliorer ton code et le réduire si possible.
Oui c'est pour ça, si j'ai un code qui fonctionne, je suis déjà content, même s'il est pas écrit super proprement lol.
Après je commence à me dire, que je peux sûrement m'améliorer encore, mais que si c'est un métier, c'est pas pour qu'on puisse l'apprendre uniquement en ligne, sauf quelques exceptions peut-être, je pense que sinon il faut passer par des formations, etc...
Je vais quand même passer au chapitre "chaine de caractère", même si je n'arrive pas tous les exos sur les tableaux, sinon je ne finirai jamais le cours
si j'ai un code qui fonctionne, je suis déjà content, même s'il est pas écrit super proprement lol.
Le code qui fonctionne, c'est le résultat d'un travail avec réflexion sur la manière d'y arriver, décomposition en sous-problèmes, résolution des sous-problèmes et recollage des morceaux. Il fonctionne pas par magie, il faut être parti sur des bonnes bases, ou les avoir rejointes en cours de route.
> Après je commence à me dire, que je peux sûrement m'améliorer encore,
La bonne blague. D'abord tu débutes, alors faut pas s'imaginer savoir faire dès le début. Et ensuite, il y a des années d'améliorations possibles, y compris pour ceux qui débutent moins.
> Je vais quand même passer au chapitre "chaine de caractère", même si je n'arrive pas tous les exos sur les tableaux, sinon je ne finirai jamais le cours
Malheureusement, il est assez probable que l'impasse que tu envisages de faire sur les tableaux te conduira à un blocage assez rapidement (une chaîne étant un tableau de caractères, en quelque sorte).
> je pense que sinon il faut passer par des formations, etc...
Il faut surtout passer par beaucoup de pratique. Mais des cours, des bouquins, c'est pas inutile. Ca fait 50 ans que la programmation est un métier, des bonnes pratiques et des savoir-faire ont émergé pendant tout ce temps, essayer de les réinventer tout seul en autodidacte mode génie solitaire, ça risque d'être un peu dur.
Sauf que (à vous de me dire si je me trompe), mais je n'ai pas l'impression de bloquer sur les tableaux, j'ai compris ce qu'était un tableau, comment les afficher etc... c'est plus l'utilisation de la boucle for pour faire des déplacement de chiffre ou chose dans ce genre que je ne comprends pas.
Un peu comme les pointeurs, malheureusement il n'y a pas d'exo spécifiques pour s'entrainer avec, mais j'ai compris leur fonctionnement et leur intérêt, cependant je ne suis pas certain pour autant que je saurai bien les utiliser.
Justement je ne sais pas ce qu'on appelle "moins débuter", puisqu'en quelques sortes, "débutant"ne veut absolument rien dire. Je suis sans doute débutant par rapport à beaucoup ici, mais je n'ai pas commencé hier non plus, comme j'ai dit, j'avais déjà fait le cours quand le site se nommait "siteduzero". Sauf que clairement je n'ai pas intégré correctement, donc ça fait que j'en suis pas à un stade très avancé c'est sûr.
> Je vais quand même passer au chapitre "chaine de caractère", même si je n'arrive pas tous les exos sur les tableaux, sinon je ne finirai jamais le cours Comme l'a dit michelbillaud, si tu ne maîtrise pas les tableaux, tu n'ira pas loin. > c'est plus l'utilisation de la boucle for pour faire des déplacement de chiffre ou chose dans ce genre que je ne comprends pas. Les boucles sont une partie essencielle de la programmation. Je pense qu'il faudrait investir du temps pour en comprendre tous les aspects et variantes. Tu n'as pas parlé des boucles while ou do ... while qui ne seront pas plus évidentes pour toi si tu ne comprends pas les for.
Le Tout est souvent plus grand que la somme de ses parties.
Je n'ai pas l'impression d'avoir autant de mal avec les boucle while pourtant.
De toutes façons il n'y a pas assez d'exercices pour progresser sur les boucles spécifiquement, ou alors il faut, comme l'a dit Michelbillaud, passer par des bouquins, etc..., mais de toutes façons je vais bloquer à un moment, car j'ai regardé vaguement les autres chapitres, notamment sur les ouvertures de fichier, et chez moi les fichiers ne s'ouvrent pas, donc comme ça c'est réglé.
J'ai l'impression que tu veux aller trop vite et tu sautes des étapes. Une boucle for ce n'est rien dautre qu'une boucle while condensée: int i=0; while(i < taille) { // blabla ... i++; } Tu veux des exercices: + affiches les éléments du tableau à l'envers du dernier au premier. + tu as un tableau de 100 positions rempli avec 50 valeurs au début. Tu tasses les éléments après la position34 jusqu'à la position 50 de une position vers la droite et tu mets une nouvelle valeur en position 34.t
Le Tout est souvent plus grand que la somme de ses parties.
Je n'ai pas l'impression d'avoir autant de mal avec les boucle while pourtant.
De toutes façons il n'y a pas assez d'exercices pour progresser sur les boucles spécifiquement, ou alors il faut, comme l'a dit Michelbillaud, passer par des bouquins, etc..., mais de toutes façons je vais bloquer à un moment, car j'ai regardé vaguement les autres chapitres, notamment sur les ouvertures de fichier, et chez moi les fichiers ne s'ouvrent pas, donc comme ça c'est réglé.
On a du mal avec un peu tout en fait.
les bouquins, c'est après l'initiation. Et l'initiation, c'est boucles, tableaux, fonctions, chaînes, etc. Allons-y doucement. C'est normal d'avoir des difficultés à apprendre des trucs, surtout des trucs qu'on connait pas déjà :-) Faut juste persévérer.
A moins d'avoir un système d'exploitation écrit par soi même qui tourne sur un ordinateur soudé à la main, y a pas de raisons de ne pas pouvoir ouvrir des fichiers, si on s'y prend correctement (et si ils sont à l'endroit où on essaie de les ouvrir). Et si on ne s'y prend pas bien, ce qui arrive souvent, ça doit se voir dans le code. C'est assez déterministe, les ordinateurs.
PS: quand on disait que l'exercice "débrouillez-vous pour trier le tableau" arrive trop tôt dans ce cours, c'était pas une blague. Ceci dit, même si on n'y arrive pas forcément, c'est d'avoir essayé qui fait progresser. Pas d'avoir réussi. L'embêtant, c'est que c'est pas trop motivant quand on a l'impression de pas y arriver.
Ce n'est pas parce qu'on sait faire du béton que pour autant on sait construire un mur.
Ce n'est pas parce qu'on sait manipuler un tableau en C que pour autant on sait /en trouver la valeur minimum/le trier/l'inverser/en faire la somme des valeur/trouver une valeur particulière … et encore je ne parle pas de choses bien plus utiles et plus complexes à faire avec un tableau.
Ce n'est pas forcément avec les tableaux que tu as du mal, mais avec ce que tu dois faire (dans le sens que demander à l'ordinateur de faire).
Je ne pense pas que le problème du tri vient trop dans le cours d'OCR car il est structurellement mal foutu. C'est surtout qu'à aucun moment on n'apprend à réfléchir sur comme faire pour écrire un code qui suit une idée réfléchie ⇒ pas de notions d'algo = peine perdu pour l'apprentissage d'un langage quel qu'il soit.
Je sais que c'est rébarbatif de faire de l'algo quand on a surtout envie de «pisser du code comme un pro». Pour autant que je me souvienne de l'époque bénie de mon apprentissage en fac, nous n'avions pas de cours cloisonnés, ils se nourrissaient les uns les autres. Ce qu'on apprenait en algo on pouvait l'appliquer en C ; Ce qu'on apprenait en BDD, en techniques de modélisation, en réseau, en OS, en … on finissait par tout appliquer dans des projets qui mêlaient tout ce qu'on apprenait. C'est pourquoi j'ai trouvé un peu ridicule l'accroche du «un cours pour devenir un bon programmeur en C». C'est juste un gros pipeau.
Et encore le tri est certainement l'un des sujets les plus abordés. Le bestiaire des algorithmes de tri est impressionnant !
Il y a des tris qui sont dit naïfs car ils imitent ce que l'on fait souvent nous humains à la main comme bubble sort ou selection sort (avec lequel tu as du mal). Il y a les tris idiots comme random sort ou bogo sort. Des tris qui ne comparent jamais les éléments entre eux comme radix sort (et qui te permettent par exemple de trier rapidement un jeu de 32 cartes en main en 5 passes). Il y a même des tris particuliers avec lesquels on ne peut pas échanger des éléments mais uniquement inverser des portions de tableau comme un tas de crêpes d'où le nom de pancake sort. Il y en a encore d'autres qui sont très particuliers car ils utilisent des techniques comme la récursivité (quicksort) ou des structure de données complexe comme des tas de Leonardo (smooth sort Pierrot). Pire il y en a qui n'ont pas encore d'implémentations possibles actuellement comme spaghetti sort et d'autres comme Shell sort dont on ne comprend pas encore tout à le fonctionnement optimal.
Je te rassure, nul besoin de les connaître tous !
Mais il est sans doute nécessaire d'avoir des notions en algo pour comprendre même les plus simples et surtout pouvoir efficacement implémenter des algorithmes que toi tu inventeras …
Il y a sur le site du zeste de savoir quelques tutos sur les algos comme : Algorithmique pour l'apprenti programmeur. Il n'y a pas d'implémentation proposée en C, mais en Python par exemple … mais c'est un bon exercice, je pense, que de le pratiquer en parallèle avec un cours C (comme celui du zeste de savoir Le Langage C).
Il y a meme un super bon tuto sur le tri par sélection (aka selection sort) avec du C pour ton plus grand bonheur …
Il y a des tris qui sont dit naïfs car ils imitent ce que l'on fait souvent nous humains à la main
Il me semble que c'est une compétence clé quand on fait de la programmation : savoir traduire en algorithme ce qu'on fait à la main. D'ailleurs je trouve que les exercices de tri doivent être faits ainsi (et non en appliquant bêtement un algorithme donné).
C'est quelque chose que je crois savoir bien faire (contrairement à la programmation pure) mais j'ignore absolument pourquoi (à la fac, déjà, ça se passait bien). Du coup je soupçonne que, un peu comme avec les maths ou la philo, il y a des gens qui auront toujours du mal et d'autres qui seront toujours à l'aise. Mais bon, un peu comme avec les maths ou la philo, ça se travaille et à mon avis il ne faut pas se décourager, c'est juste que pour certains ça prendra plus de temps.
Sébastien : j'espère que tu n'es pas comme moi en philo...
Il y a des tris qui sont dit naïfs car ils imitent ce que l'on fait souvent nous humains à la main
Il me semble que c'est une compétence clé quand on fait de la programmation : savoir traduire en algorithme ce qu'on fait à la main. D'ailleurs je trouve que les exercices de tri doivent être faits ainsi (et non en appliquant bêtement un algorithme donné).
Ah c'est clairement le début de tout ! Ensuite on ne voit plus un jeu de cartes de la même manière lol et l'étape d'après est de trier les cartes avec un radix sort. Mais oui, on devrait commencer les exercices sur les tris par découper de petits papiers avec des numéros … En comprenant qu'on ne peut parcourir le «tableau de cartons» uniquement avec son index et que déplacer un carton revient à copier sa valeur dans une nouvelle variable, enfin ce genre de chose. Rendre physique et tangible le tri et les actions doit certainement aider.
robun a écrit:
[...]
C'est quelque chose que je crois savoir bien faire (contrairement à la programmation pure) mais j'ignore absolument pourquoi (à la fac, déjà, ça se passait bien). Du coup je soupçonne que, un peu comme avec les maths ou la philo, il y a des gens qui auront toujours du mal et d'autres qui seront toujours à l'aise. Mais bon, un peu comme avec les maths ou la philo, ça se travaille et à mon avis il ne faut pas se décourager, c'est juste que pour certains ça prendra plus de temps.
En plus on est à une époque où en C il ne sert à rien de vouloir être plus futé qu'un compilo. Il vaut mieux bien l'informer que d'essayer de le surpasser. Mais bon … après les détails d'implémentations comptent encore entre l'ordre de stockage des données ou la prise en compte de l'accès aux caches par exemple.
Pour ceux que ça intéresse, voici une explication française du Radix Sort: https://fr.wikipedia.org/wiki/Tri_par_base Pas tout à fait recommandé pour le tri de très grand nombres avec des ordres de grandeurs très différents: 0 à 100 milliards. C'est vrai qu'on n'y fait pas de comparaison des valeurs de l'ensemble.
Le Tout est souvent plus grand que la somme de ses parties.
Perso, si au lieu de faire comme le recommande la page wikipedia pour trier un jeu de 52 cartes, tu encodes les cartes différement en base 2 tu n'as plus besoin que de tes deux mains et pas de tapis comme stockage temporaire … et 6 passes.
PierrotLeFou a écrit:
[...] Pas tout à fait recommandé pour le tri de très grand nombres avec des ordres de grandeurs très différents: 0 à 100 milliards. C'est vrai qu'on n'y fait pas de comparaison des valeurs de l'ensemble.
Mais comme tous les tris sans comparaisons d'éléments entre eux, il s'accommode facilement de jeux de données qui ne tiennent pas en RAM. Il est efficace (dans le sens complexité temporelle linéaire) quand la clé de tri est de taille fixe. Il s'adapte aussi très bien aux listes chaînées. Malheureusement il n'est pas stable.
Mais bon dans le monde réel les implémentations de tri sont souvent hybride en fonction de la taille des donnée, Un algorithme pour traiter les gros morceau et un autre pour les petits. Il me semble que dans la gnu libc, on commence par un quicksort, puis à partir d'une certaine les sous tableau sont triés par heapsort et pour finir les petites instances par un insertion sort.
Python utilise aussi une approche hybride → timsort.
je n'ai pas l'impression de bloquer sur les tableaux, j'ai compris ce qu'était un tableau, comment les afficher etc... c'est plus l'utilisation de la boucle for pour faire des déplacement de chiffre ou chose dans ce genre que je ne comprends pas.
C'est là qu'il y a une méprise courante (entretenue par les marchands de formations).
Il ne s'agit pas simplement "d'avoir vu" ou "d'avoir compris" (en général, l'impression d'avoir compris), il s'agit acquérir un savoir-faire, qui consiste à voir comment combiner les éléments de base d'un langage de programmation (boucles, variables, tableaux) pour arriver à faire quelque chose. Sur des problèmes différents à chaque fois. C'est donc beaucoup plus que la répétition de ce qu'on a déjà vu.
Ce qui fait qu'on constate un blocage du débutant quand on passe des exercices à un projet où il va falloir décomposer le boulot soi-même pour y arriver. Surtout si les exercices de préparation, il croit (de bonne foi) avoir compris la solution trouvée quelque part après avoir cherché mollement.
Je suis même pas sûr d'avoir bien compris ce que vous appelez l'algorithmie à vrai dire.
Pour répondre à robun, j'ai toujours était nul en philo mdr. Mais je pense pas que ça joue beaucoup au niveau programmation/algo, d'ailleurs, même être bon en maths n'apportent strictement rien contrairement à ce qu'on entend parfois, car je n'ai jamais eu aucun souci dans cette matière et ce n'est pas pour autant que tout m'a paru logique immédiatement en programmation.
J'ai aussi l'impression que même une fois le cours fini on ne sait pas faire grand chose d'utile au final, et ça non plus ça ne motive pas trop. Tout comme ne réussir aucun exercice (comme le disait PierrotLeFou je crois).
Enfin en réalité j'ai réussi TP "plus ou moins", mais bon, j'ai l'impression que c'est un peu "qui n'y arriverait pas franchement ?" (je veux dire en ayant suivi le cours attentivement). D'ailleurs j'ai aussi réussi à faire les améliorations, comme compter le nombre de coups pour trouver, etc..., et ce TP utilise justement au moins 1 boucle, d'ailleurs, volontairement, je l'ai fait une fois en utilisant la "for", puis après plus "classiquement" on va dire, en utilisant la boucle "while", ça ne m'aide pas pour autant dans les travaux sur les tableaux lol.
Alors que trier le tableau dans l'ordre croissant, même en ayant suivi correctement le cours, ce que je pense avoir fait, je ne vois pas qui pourrait y arriver sauf s'il a déjà des bases dans ce domaines.
Donc oui je pense qu'il arrive beaucoup trop tôt. Je vais tenter de refaire des exercices que j'ai déjà fait mtn que j'ai laissé un peu de temps passer, mais bon je vois pas pourquoi j'y arriverai mieux que la dernière fois mdr.
Je suis même pas sûr d'avoir bien compris ce que vous appelez l'algorithmie à vrai dire.
Un algorithme, c'est la description précise d'une suite d'opérations à effectuer pour, à partir de données, fabriquer un résultat déterminé. Ou plus exactement, les faire réaliser par un exécutant stupide. Une fois qu'on sait la suite d'opérations à effectuer, y a plus qu'à programmer ça dans un langage.
L'algorithmique, c'est l'étude des algorithmes.
Ca part de l'apprentissage de l'algorithmique de base, genre trouver le maximum de deux nombres, faire des boucles, etc. ça continue avec la connaissance des algorithmes classiques, les méthodes de construction, l'étude rigoureuse des algorithmes (complexité), les techniques de preuves (correction, terminaison), etc.
personnellement, je n'emploie pas "algorithmique" pour les bases, faut pas exagérer, comme je ne mets pas l'apprentissage des tables d'addition dans les mathématiques.
Il n'empêche qu'il faut apprendre ça avant de prétendre programmer. Et que ce n'est pas si évident, ça demande du boulot.
Il n'empêche qu'il faut apprendre ça avant de prétendre programmer. Et que ce n'est pas si évident, ça demande du boulot.
- Edité par michelbillaud il y a 28 minutes
C'est tellement vrai, et il y a tant de «développeurs» qui dans le meilleur des cas n'ont en pas conscience et dans le pire des cas s'en foutent éperdument car il y a tout ce qu'il faut dans les frameworks … De plus si on rajoute à ça la mauvaise presse qui est faite aux «algorithmes» comme «putain j'ai pas de vues c'est à cause de l'algorithme youtube !», ou les titres putaclicks «comment les algorithmes vont vous mettre au chômage» … 'fin bref.
Mais il ne faut pas redouter les algos … on les utilise tous les jours et même inconsciemment. Nous avons tous appris l'algorithme qui nous permet de lacer nos chaussures ou celui qui nous permet de faire un bœuf bourguignon. La métaphore de la recette est assez éloquente :
on a une liste d'ustensiles (four, couteaux, bol, …) ;
on a une liste d'ingrédients (sel, viande, farine, …) ;
on a une liste d'actions utilisant les ustensiles et manipulant les ingrédients (à l'aide du couteau et de la planche à découper, prendre la viande et la découper en cube de 2cm de côtés) certaines de ses actions sont plus complexes et sont des algorithmes à elles-seules (émincer un légume = utiliser un couteau et une planche à découper pour découper en fine lamelles d'égales épaisseurs le légume --- tu remplaceras légume par oignon, courgette, carotte …).
En développement c'est un peu pareil :
on a une liste d'outils (processeurs, OS, IDE, framework, clavier, …) ;
on a une liste de structure de données (entier, flottant, tableau, liste, graphe, …) ;
on a une liste de procédures permettant de manipuler ces structures de données (ajouter des entiers, déterminer la primalité d'un entier, trouver le minimum d'un tableau, trier une liste, …) ; certaines procédures sont plus complexes …
Car il ne faut pas oublier que programmer, du moins la version «informatique», c'est aussi manipuler des données. Pour ne citer que N. Wirth :
J'ai réussi sans revoir aucune notion du cours, à écrire un programme qui compte le nombre de "e" (ou "E") dans une chaine de caractère (un tableau donc).
C'est pour ça que je dis : je pense avoir compris à peu près les tableau et comment les parcourir, mais du coup, je trouve ça étrange d'avoir autant de difficulté à sortir le max ou le minimum d'un tableau. Ou bien le placer en début de tableau, ça devrait être relativement facile il me semble.
Si tu as réussi à compter le nombre de 'e' ou 'E', c'est que tu as utilisé une variable qu'on appelle un "compteur". De plus, tu sais comment tester avec un if si le caractère est un 'e' ou 'E'. Est-ce si différent que d'utiliser une variable qui contient le "maximum"? Quand tu trouves un 'e', tu augmentes ton compteur. Quand tu trouves quelque chose plus grand que le maximum, tu mets cette valeur dans le maximum. Et de là, tu peux avoir une variable qui contient la position du maximum au lieu de sa valeur. À la fin de la boucle, tu inrterchanges les éléments se trouvant à la première position et celui se trouvant à la position du maximum.
Le Tout est souvent plus grand que la somme de ses parties.
Il y a sûrement quelque chose de fondamentalement différent entre les deux dans ta tête. OK ce n'est pas pareil, mais très proche. Je suppose que tu l'as déjà dit plus d'une fois, mais dis le autrement. Qu'est-ce que tu ne saisis pas dans le fait de chercher le minimum / maximum d'un tableau? Voici un petit code commenté. Note que le tableau n'est pas du tout modifié dans cette fonction. - int minimumTableau(int tableau[], int taille) { // C'est mon style que de mettre l'accolade sur la ligne de contrôle. int minimum = tableau[0]; // Je suppose au départ que le minimum est dans la première position. for(int i = 1; i < taille; i++) { // Je cherche à partir de la seconde position. if(tableau[i] < minimum) // Je vérifie si la valeur à la position courante est inférieure au minimum déjà trouvé. minimum = tableau[i]; // Si c'est le cas, je place la valeur associée à la position courante dans le minimum. } // Fin de la boucle de recherche. return minimum; // Je retourne la valeur minimum du tableau. } // Ouf! Fin de la fonction.
Le Tout est souvent plus grand que la somme de ses parties.
Comme je te l'ai déjà dit … ce n'est pas un problème C, c'est un problème d'algo.
Suis un cours d'algo ou tu apprendras progressivement à avoir une approche et une méthode de résolution de problème. Un fois que tu as pondu l'algo il faut le transcrire en un langage que ce soit C ou autre … c'est là que tu devras te poser des questions si tu n'y arrives pas.
Je vais changer de sujet puisque le seul moyen pour avancer est de s'entrainer à écrire des codes, en espérant comprendre de mieux en mieux ce qui n'est pas gagné, bref.
De toutes façons, comme j'en ai rapidement parlé, plus loin dans le cours, je suis bloqué pour l'ouverture de fichier.
Ou alors j'ai mal compris, mais pour moi, si j'en crois le cours, le code que je vais mettre ci-dessous devrait ouvrir le fichier "test.txt" :
Sachant que j'ai mis ce fichier dans le même dossier que l'exécutable, d'ailleurs pour être sûr que le souci n'était pas là, je l'ai copié dans tous les dossier du projet vu qu'il n'y en a pas beaucoup lol.
Et pas moyen, il ne s'ouvre pas malgré tout ça.
EDIT : j'ai écrit un mini pendu, mais je cherche encore ce qui va pas dans mon code car d'après le cours faut utiliser tout ce qu'on est censé savoir lol (pointeur, fichier, etc...) et moi j'ai ça :
int main(int argc, char *argv[])
{
int i = 0;
char mot_secret[] = "ROUGE";
char mot[] = "_____";
char lettre[] = "NULL";
do {
printf("Entrez une lettre : ");
scanf("%s", lettre);
printf("Vous avez choisi : %s\n\n", lettre);
for (i = 0; i < 5; i++) {
if (mot_secret[i] == lettre[0]) {
mot[i] = lettre[0];
}
}
printf("\n\n%s\n\n", mot);
} while (mot[5] != "ROUGE");
}
J'ai sûrement des variables inutiles, j'en sais rien, je n'ai pas du tout relu pour l'instant.
- Edité par SébastienTellier 5 juillet 2021 à 10:54:13
Qu'est-ce que tu entends par « il ne s'ouvre pas » ?
Parfois il y a malentendu et on s'imagine qu'un éditeur va s'ouvrir. Mais il faut se mettre du point de vue du programme, pas de l'utilisateur. Pour l'utilisateur, ouvrir un fichier, c'est faire apparaître son contenu à l'écran (pas son vrai contenu fait de 0 et de 1, mais une interprétation de son contenu). Pour le programme, ouvrir un fichier, c'est copier son contenu temporairement dans la mémoire vie (son vrai contenu fait de 0 et de 1). Le programme pourra alors agir sur les données (il ne peut agir que sur la mémoire vive, pas sur le disque).
De même, fermer un fichier ne signifie pas, pour le programme, fermer un éditeur, mais signifie vider la copie temporaire qui était en mémoire vive (si on oublie, c'est une fuite mémoire).
Si le problème n'était pas ce malentendu, je ne vois pas.
Concernant le mini-pendu, apparemment tu ne testes qu'une lettre. Tu devrais permettre à l'utilisateur de proposer plusieurs lettres, sinon il ne risque pas de toutes les trouver. Pour ça il faut utiliser une boucle :
Tant que l'utilisateur n'a pas trouvé toutes les lettres :
Demander à l'utilisateur une lettre
Tester la lettre // c'est la boucle 'for (i)' de ton programme
Erratum : tu as bien une boucle do... while. Je ne l'avais pas vue car son contenu est mal indenté.
Ouvrir un fichier en lecture sert à le consulter, par exemple à lire des données. L'idée, c'est qu'au lieu de lire les données du clavier, on lit les données du fichier. C'est automatique et non interactif.
Par exemple, pour le pendu, le programme lit le fichier des mots du dictionnaire puis en choisir un aléatoirement. Inutile d'afficher la liste.
-----
Pour le mini-pendu j'ai lu trop vite. Il y a un problème à la condition d'arrêt :
while (mot[5] != "ROUGE")
'mot[5]' est la dernière lettre du mot. Or ce que tu veux comparer, c'est tout le mot : 'mot' tout court. Donc tu veux faire :
while (mot != "ROUGE")
Sauf que... En C, l'opérateur != n'est pas utilisable avec les chaînes de caractères (pour des raisons subtiles liées à la façon dont les chaînes de caractères sont représentées). Il faut écrire :
while (strcmp(mot, "ROUGE") != 0)
où 'strcmp' est un fonction de <string.h>, qu'il faut #inclure. Les chaînes de caractères en C, c'est compliqué... (Le choix de leur représentation est d'ailleurs souvent considéré comme une erreur historique de l'histoire de la programmation.)
Pour bien comprendre la notion d'ouverture/fermeture de fichier il faut revenir au bon vieux temps des fichiers sur bandes magnétiques.
Dans ce temps-là, il y avait un monsieur (opérateur) qui travaillait dans la salle de l'ordinateur, et dont le rôle était d'aller chercher les bandes magnétiques sur des étagères pour les mettre dans des lecteurs de bandes magnétiques.
1951-1968 Early Computer Magnetic Tape Units- History IBM, UNIVAC, RCA, AMPEX - Educational Video
Quand un programme (un job) exécutait un "open" - ou équivalent - le programme s'arrêtait, un message s'affichait sur le terminal (console) de l'opérateur, en lui demandant d'aller chercher une bande magnétique (avec son nom) et de l'installer dans un lecteur inoccupé.
Quand c'était fait, l'opérateur tapait une commande pour dire que c'était fait, ce qui permettait au programme de reprendre et de traiter les données.
Dans le programme, un "close" lançait un rembobinage de la bande, et indiquait à l'opérateur que la bande pouvait être rangée.
---
Bref, de nos jours "ouvrir un fichier", c'est associer un fichier qui est stocké quelque part à un "handle" qui permet à un programme d'agir dessus (numéro de descripteur, FILE*, peu importe). Eventuellement ça peut garantir aussi un accès exclusif (verrouillage) pour être sur qu'un seul programme le modifie. Le verrouillage cesse quand le fichier est "fermé".
---
Dans mon premier boulot rémunéré, je démarrais le NCR 8250 le matin avec la bande magnétique et tout ça en arrivant (l'ordi servait au traitement de chèques l'après midi, je l'avais pour moi tout seul le matin et en fin d'après midi !)
Mon pendu fonctionne quand même, enfin du moins avec la réponse de robun sur la condition d'arrêt car j'avais aussi essayé "mot ! = "ROUGE" " mais ça ne fonctionnait pas effectivement.
Le seul truc c'est que je n'ai pas un mot choisi au hasard et ça c'est un peu dommage.
Je vais changer de sujet puisque le seul moyen pour avancer est de s'entrainer à écrire des codes, en espérant comprendre de mieux en mieux ce qui n'est pas gagné, bref.
[...]
Nouveau sujet … alors il faut créer un nouveau sujet sur le forum aussi …
× 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.
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.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.