Discussion :

[Neckara]

EDIT (Melem) : Cette discussion fait suite à la discussion indiquée ci-dessous au sujet de l'utilisation de while (!feof(f)) pour détecter la fin d'un fichier. La discussion originale se trouve ici.

Le prof auquel j'ai parlé est bien conscient que feof n'est pas conseillé.
Mais on l'étudie par soucis de rétro-compatibilité.

Et c'est utile de savoir utiliser feof de cette manière pour savoir lire plus facilement certains codes qui utiliseraient cette manière.

De plus il affirme que même certaines bibliothèques (même standard) ne sont pas écrites proprement.
Comme scanf qui n'est pas aussi une fonction propre.
En parlant de propre, est-ce que vous pensez toujours à tester les valeurs retournée dès qu'une fonction retournée une valeur? Car logiquement, il le faudrait.

Voilà, mais l'utilisation de feof n'est pas non plus un drame^^

[Obsidian]

Ce n'est pas ce qu'on a dit !

feof() n'est pas une fonction dépréciée. C'est toujours de cette manière que l'on s'informe de la fin du fichier qu'on est en train de lire.

Ce qui est dit ici, c'est qu'on n'utilise pas cette fonction de la manière dont on pourrait s'y attendre. Ce qu'il faut, c'est d'abord détecter une impossibilité d'aller plus loin avec les fonctions de lecture habituelles, puis utiliser feof() et ferror() pour savoir si cette impossibilité est due à une fin de fichier normale ou à une erreur.

C'est important parce que non seulement c'est contre-intuitif, mais que beaucoup d'autres langages (y compris les anciens BASIC), eux, proposent une fonction EOF qui fonctionne comme attendu.

[Jean-Marc.Bourguet]

Le prof auquel j'ai parlé est bien conscient que feof n'est pas conseillé.

Le problème n'est pas que feof n'est pas conseillé. feof est conseillé pour déterminer la cause de l'échec d'une lecture. Le problème est que feof comme condition de controle d'une boucle est un bug dans 99,99% des cas, et redondant ou inutilement compliqué dans les autres. Ton exemple est naturellement un exemple du bug. Reprennons-le:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while (!feof(fichier))
    {
        nbc=fread(&td[30*j],sizeof(char),30, fichier);
        j++;
        nbt=nbc+nbt;
    }

On ne sort de cette boucle que si on atteint la fin du fichier. Que se passe-t'il si il y a une erreur (mauvais section, timeout pour un disque monté par le réseau,...)? fread va échouer (mais tu ne testes pas le résultat pour savoir si des caractères ont bien été lus) mais feof va rester à false, donc une boucle infinie.

Mais on l'étudie par soucis de rétro-compatibilité.

Compatibilité avec quoi? Pour que tous les programmes aient les mêmes bugs?

Et c'est utile de savoir utiliser feof de cette manière pour savoir lire plus facilement certains codes qui utiliseraient cette manière.

Visiblement, tu ne sais pas utiliser feof de cette manière vu qu'il y a un bug.

De plus il affirme que même certaines bibliothèques (même standard) ne sont pas écrites proprement.

Je m'amuse pas à aller voir le code des bibliothèques. Quant à juger de leur propreté, il faut d'abord connaître les contraintes avec lesquelles elles ont été écrites.

Comme scanf qui n'est pas aussi une fonction propre.

Critiquer en fonction de critères actuels des choix faits il y a plus de 30 ans dans un autre contexte, c'est facile.

Oui il y a des choses qu'on ferait différemment (gets, strncpy viennent d'ailleurs bien avant scanf). En passant, je ne tenterais pas un feof prédictif (ça a tendance à poser des problèmes quand on a un périphérique interactif par exemple et de toute manière on se retrouve à devoir traiter des problèmes qu'on ne peut détecter que pendant l'opération d'entrée pure, on peut même se retrouver à avoir un feof qui doit sauter les blancs et les fins de ligne).

En parlant de propre, est-ce que vous pensez toujours à tester les valeurs retournée dès qu'une fonction retournée une valeur? Car logiquement, il le faudrait.

Il faut tester le résultat de toute fonction pouvant générer une erreur. Le problème est que ça gène la clareté des explications et donc qu'on les saute quand on veut expliquer autre chose. Mais il faudrait qu'au moins ils insistent dessus pendant les exercices.

Voilà, mais l'utilisation de feof n'est pas non plus un drame^^

L'utilisation de feof pour contrôler une boucle n'est pas un drame, c'est un bug, parfois difficile à mettre en évidence par des tests quand il n'est visible qu'en cas d'erreur (il y a d'autres symptomes plus facilement mis en évidence mais qui se retrouvent souvent partiellement réglés par des conditions supplémentaires dans la boucle; on a donc un code incorrect et plus compliqué que le code correct). Le bug peut après tourner en drame.

[Melem]

Le prof auquel j'ai parlé est bien conscient que feof n'est pas conseillé.

Il ne devrait pas non plus le conseiller alors. Et si c'est plus fort que lui, il devrait au moins inviter ses élèves à ne pas faire comme lui.

Et c'est utile de savoir utiliser feof de cette manière pour savoir lire plus facilement certains codes qui utiliseraient cette manière.

Je pense que c'est plus important de savoir l'utiliser correctement pour pouvoir corriger facilement certains codes l'utiliseraient de cette manière (entre autres).

Bon, je m'arrête parce que Jean-Marc a pratiquement tout dit.

[Neckara]

En IUT le but est d'apprendre.
Les profs doivent se tenir au programme national.

Ensuite, j'ai bien compris que feof ne devrait pas être utilisé pour arrêter une boucle de lecture.

Mais d'un point de vu éducatif, les personnes faisant le Programme Nationnal ont jugé qu'il valait mieux l'utiliser en premier comme cela.
En tp, on est pas censé avoir des erreurs et si jamais il s'en produit une un simple ctrl+C et c'est fini.
Il est fort probable qu'on sera un jour confronté à une boucle infinie à cause d'une erreur et que les professeurs en profitent pour rebondir et nous parler de ferror, nous dire que maintenant, il ne faudra plus utiliser feof pour les condition de fins de boucles de lectures mais plutôt tester les retours des fonctions de lectures, etc...

Ensuite, pour la rétro-compatibilité, je ne fait que rapporter les paroles de mon prof.
Si j'ai bien compris, certains vieux programmes sont construits avec feof et si on essaye de l'enlever, il y aura beaucoup de modifications à faire donc il vaut mieux comprendre comment cela fonctionne.

Je m'amuse pas à aller voir le code des bibliothèques. Quant à juger de leur propreté, il faut d'abord connaître les contraintes avec lesquelles elles ont été écrites.

Je n'ai jamais dit que les personnes ayant codée des bibliothèques ont mal codé. Juste que certaines bibliothèques ne sont pas propre, c'est juste une constations.
Sinon pour scanf, en quoi je critique?
Aujourd'hui, il n'est pas très propre. C'est un fait rien de plus!
Juste pour montrer qu'une chose qui n'est pas propre, s'il est bien utilisé, ce n'est pas la fin du monde.

Ensuite, certaines bibliothèques sont tout aussi sale que feof + ferror comme fin de condition de boucles de lectures pourtant elles fonctionnent depuis plusieurs années et il se peut même que toi-même tu les utilises.

Ensuite, j'ai bien compris qu'il ne faut pas utiliser feof comme cela depuis quelques posts déjà.
Là je ne faisais que dire la raison pédagogique à son utilisation en IUT.
Il ne s'agit pas de faire un programme vital pour un hôpital ou autre mais juste apprendre les bases du C.

Ensuite, tu dis qu'il faudrait que les profs insistent sur le fait de tester les fonctions de lecture en cours.
Mais es-tu prof?
La base de tout enseignement est de propager un discours faux pour simplifier les choses puis au fur et à mesure qu'on avance, de se rapprocher d'un discours vrai en rentrant plus sur les détails.
C'est la base même de toute l'éducation française qui prend la philosophie de Platon sur le discour vrai/discours faux (La République).

Si en maternelle, au lieu d'apprendre à compter, on apprenait les fondement des mathématiques, si au lieu d'apprendre à parler, on leur apprenait l’étymologie des mots ils seraient complètement perdu.

En IUT informatique, c'est pareil, déjà que la moitié de la promo n'a pas son premier semestre, si en plus on dit que pour fgetc il faut tester ceci, pour fscanf ceci, fgets cela. A par les embrouiller et leur faire faire écrire n'importe quoi...

Si en tp on devait tester à chaque fois la valeur de retour de toutes les fonctions qu'on utilise, on perdrait beaucoup trop de temps.
On est en IUT pour apprendre, mais on ne peut pas tout voir à la fois.
Il faut bien commencer quelque part.

[souviron34]

La base de tout enseignement est de propager un discours faux pour simplifier les choses puis au fur et à mesure qu'on avance, de se rapprocher d'un discours vrai en rentrant plus sur les détails.
C'est la base même de toute l'éducation française qui prend la philosophie de Platon sur le discour vrai/discours faux (La République).

Là je t'arrête tout de suite..

Autant en philo il peut y avoir contradiction, hausse de la réflexion par des thèses/antithèses, autant en sciences ceci est faux.

La base d'un enseignement scientifique est de prêcher le VRAI, quiitte à le simplifier au départ..

Or l'informatique, est, aux dernières nouvelles, un enseignement scientifiique, démontrable, et répétable..

Ne souffrant aucune ambiguité lorsqu'une fonction est définie..

N'essaie pas de justifier cette pratique d'un (de plusieurs ?) profs.. Elle est simplement injustifiable.. Et d'ailleurs si tu n'avais pas posé la question il n'aurait rien dit.

[Neckara]

Si tu simplifie, ce n'est pas vrai, c'est faux.
C'est un mensonge par omission.

Ce n'est pas quelques profs qui font cela mais tout le système éducatif.

En terminal S, on utilise bien les équivalence souvent à tord et à travers par exemple.
En physique, on va souvent écrire des égalités fausses car elles ne sont que des approximations.
Dès que tu fais une mesure, tu écris forcément un résultat faux.
Etc...

[diogene]

Si en maternelle, au lieu d'apprendre à compter, on apprenait les fondement des mathématiques,...

Mais on les fait compter juste, pas faux. Ce n'est qu'une ébauche des mathématiques, mais elle n'est pas fausse.

Une salle de classe n'est pas un tribunal où on doit dire la vérité, rien que la vérité et toute la vérité. Mais on doit dire la vérité et rien que la vérité. On peut bien sûr utiliser une image pour faire comprendre les choses, mais bien préciser que ce n'est qu'une image. Il ne faut pas confondre un discours faux avec un discours vrai mais volontairement épuré. Il ne faut pas qualifier de résultat faux un résultat juste compte tenu des approximations utilisées (comme en physique) et clairement comprises.

L'ennui est qu'une fois que les concepts erronés sont "assimilés", il devient beaucoup plus difficile de les extirper et ils engendrent alors des conflits, des contradictions, des incompréhensions avec la suite de l'enseignement.

Débat déjà vu et assez polémique.


Je ne vois pas pourquoi les étudiants trouveraient plus difficile d'apprendre l'utilité des valeurs de retour de fscanf(), fgets() ou fread() plutôt que feof() et ferror(). Quant à choisir, je crois plus raisonnable de faire dans un premier temps l'impasse sur feof() et ferror(), que sur ces valeurs de retour. Après tout, on en a besoin que si on veut préciser les raisons de la fin du flux d'E/S.

Dès que tu fais une mesure, tu écris forcément un résultat faux.

Que veux dire faux ici ? l'incertitude est consubstancielle à notre monde quelle que soit la précision de l'instrument de mesure (cf méca. quantique). Alors le monde est faux ?

[souviron34]

En physique, on va souvent écrire des égalités fausses car elles ne sont que des approximations.

euh , franchement il faut que tu revois tes bases


En physique tu as 2 choses :

• de la théorie : des équations mathématiques exactes
  
  
• de la pratique : des mesures à partir desquelles soit tu veux confirmer ou infirmer une théorie, soit à partir desquelles tu veux tirer une équation empirique, faute de théorie, ou une valeur numérique (constante).

Quand on t'a appris la loi des gaz parfaits et le Prermier et 2ième principe de la thermodynamique, ce sont des équations justes.

Dont le domaine de validité peut être restreint, certes, puisique l'ntérieur des étoiles reprend ces lois avec des termes en plus, mais qui sont JUSTES.

Comme on te l'a dit plus haut, il ne faut pas confondre VERITE et APPROXIMATION..

La Loi de Newton est vraie, la valeur de la constante est une approximation... Tout comme E=mc2 est vrai, alors que la valeur de c est une approximation...

Ceci dit, ce débat est largement HS, mais c'est pour ta gouverne et l'établissement de ta pensée future..



PS: je rajoute que quand je lis dans ton post :

Si en tp on devait tester à chaque fois la valeur de retour de toutes les fonctions qu'on utilise, on perdrait beaucoup trop de temps

c'est la même (fausse) justification que plus tard, professionnellement, certains utilisent... (pas le temps , ça coûte trop cher..)

Tu te dis la même chose pour ne pas vériifer si tu as fait des fautes d'orthographe dans un devoir ???

Ou vérifier des équations dans un algo ??

Ou vérifier que tu as bien fermé les accolades d'un if..else ou que tes déclarations sont cohérentes avec tes usages de variable ??


La valeur de retour d'une fonction est aussi essentielle que ses arguments et son usage...

[Jean-Marc.Bourguet]

Mais es-tu prof?

Je n'ai enseigné que pendant 6 ans. Et un des principes est de ne pas enseigner quelque chose de faux; d'incomplet à la rigueur (donc on peut rafiner par la suite), mais pas de faux.

Donc ici enseigner la structure normale. Et rafiner avec la gestion des erreurs. Pas enseigner une structure qui ne fonctionne pas.

Encore que maintenant, je crois que je ne zapperais plus la gestion d'erreur pour cause de clareté de l'exposé même au début. Il y a trop de gens qui recopient simplement ce qu'on leur donne, même si on a mis en gras, rouge, clignotant qu'il faut complèter avec la gestion des erreurs.