Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C (je suis débutant en c) je ne vois d'instruction pour boucler

(je suis débutant en c) je ne vois d'instruction pour boucler

156 réponses
Avatar
bpascal123
Bjr,sr,
Voici une fonction tr=E8s simple qui r=E9agit comme s'il y avait une
boucle alors qu'en apparence il n'y en a pas :

#include <stdio.h>

void f2(int b);
void f1(int a);

int main(void)
{
f1(30);

return 0;
}

void f1(int a)
{
if( a )
f2( a - 1 );
printf("%d ", a);
}

void f2(int b)
{
printf(" . ");
if(b)
f1( b - 1 );
}

http://www.java2s.com/Code/C/Function/Functioncalleachother.htm

Merci,
Pascal
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
10 11 12 13 14
Avatar
Samuel Devulder
candide a écrit :

Non mais un code qui contient un UB ne peut rien prouver.



De toute façon, si on suit la norme, alors tous les programmes
contiennent des UB (ne serait-ce qu'à cause des overflows arithmétiques
ou des I/O non vérifiées si j'ai bien compris l'état d'esprit des thread
précédent) et donc on ne peut rien prouver à rien et tout ces threads
sont stériles.

D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main, et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main. Par contre les coup
de pieds au c*l, oui ca ils peuvent en prendre... ya tout un stock à
écouler.

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.

Comme on dit: Ils ne savaient pas que c'était impossible, alors ils
l'ont fait.

sam :)
Avatar
espie
In article <4b156ee5$0$11542$,
Samuel Devulder wrote:
D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main, et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main. Par contre les coup
de pieds au c*l, oui ca ils peuvent en prendre... ya tout un stock à
écouler.



Verifier les entrees, c'est la base.

J'ai verifie experimentalement: meme en repetant 25 fois aux etudiants
*qu'il faut toujours verifier que ce qu'on fait reussit* a partir du
moment ou ca peut echouer, j'en ai toujours qui viennent me voir apres
avoir cherche un bug pendant 30 mn, generalement 15 lignes plus loin que
l'endroit ou est le bug. Genre, une segfault, parce que le pointeur qu'ils
dereferencent, ben ils n'ont jamais verifie qu'il contenait quelque chose
de sense au moment de l'appel de fonction qui l'a initialise. Ou, sous
Unix, une tentative d'ecriture sur un fd... qui echoue parce que le fd
vaut -1, vu qu'ils n'ont jamais verifie que le open/socket/connect/pipe
avait fait quelque chose d'intelligent.

Apres un moment ca lasse. Tu te fixes une regle simple: tu refuses de
regarder du code ou au moins ce travail minimal de verification des erreurs
a ete fait. Ca te gagne enormement de temps, et la qualite du code produit
par les etudiants monte en fleche...
Avatar
Samuel Devulder
Marc Espie a écrit :
In article <4b156ee5$0$11542$,
Samuel Devulder wrote:
D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main, et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main. Par contre les coup
de pieds au c*l, oui ca ils peuvent en prendre... ya tout un stock à
écouler.



Verifier les entrees, c'est la base.



Oui... mais pas se prendre la tête la dessus quand c'est pas l'essentiel
du propos, ni même le problème original de l'OP. D'une part ca n'aide en
rien l'OP, mais en plus ca part souvent dans des digression a n'en plus
finir entre telle ou telle interprètation de la norme qui n'influence en
rien l'usage réél.

De toute facon pour les tests et le débug, moi je recommande de ne pas
se baser sur un environnement ou les choses ne sont pas reproductibles
(une saisie au clavier par exemple), et je préfère écrire les chaînes en
dur dans le code pour mettre au point le coeur de l'algo. Une fois ce
dernier validé, et les tests proprement mis dans un code de test
unitaire (pour détecter des régressions), on peut y aller des milles et
unes façon de saisir les paramètres dans un prog C (entrée clavier,
utilisation arc/argv, lecture de socket, du port série, que sais-je encore).

J'ai verifie experimentalement: meme en repetant 25 fois aux etudiants
*qu'il faut toujours verifier que ce qu'on fait reussit* a partir du
moment ou ca peut echouer, j'en ai toujours qui viennent me voir apres
avoir cherche un bug pendant 30 mn, generalement 15 lignes plus loin que
l'endroit ou est le bug. Genre, une segfault, parce que le pointeur qu'ils
dereferencent, ben ils n'ont jamais verifie qu'il contenait quelque chose
de sense au moment de l'appel de fonction qui l'a initialise. Ou, sous
Unix, une tentative d'ecriture sur un fd... qui echoue parce que le fd
vaut -1, vu qu'ils n'ont jamais verifie que le open/socket/connect/pipe
avait fait quelque chose d'intelligent.



Le truc a faire, et c'est pareil avec des stagiaires: tu les laisses
galérer un peu et corriger le problème eux-meme.. Ils verront que c'est
difficile, mais c'est normal: "c'est le métier qui rentre". S'ils n'y
arrivent pas, tu jette un œil à leur code en leur disant de ré-écrire
telle ou telle partie "en faisant comme ca, cela marchera" et qu'ils
viennent t'expliquer la différence entre leur code et l'implémentation
que tu suggère pour voir s'ils ont compris le truc.

Sinon ca sert à rien si ils trouvent toujours une bonne âme pour faire
leur boulot à leur place. Coder n'est pas seulement pisser des lignes de
texte souvent recopiées direct d'un tuto sur internet qu'on a pas
compris et venir pleurer parce que ca marche pas. C'est aussi, et
presque plus important, de savoir débugger intelligemment pour
comprendre *pourquoi* ca ne marche pas. Il est connu qu'on apprends plus
de ses erreurs que du reste.

Apres un moment ca lasse. Tu te fixes une regle simple: tu refuses de
regarder du code ou au moins ce travail minimal de verification des erreurs
a ete fait. Ca te gagne enormement de temps, et la qualite du code produit
par les etudiants monte en fleche...



Oui: il faut leur laisser galèrer un peu, ca ne fait pas de mal et après
qu'ils ont compris leur douleur, ils évitent de retomber dans les mêmes
pièges. Mais bon, il ne faut pas oublier non plus qu'il y a de vrai
neu-neus dont on se demande pourquoi ils font ou veulent faire de
l'info. Bon pour eux, une seule solution: stage dans l'équipe de qualité
à exercer bêtement mais scrupuleusement des fiches de tests.. ce sera
moins dangereux pour tout le monde.. quoi que ;)

sam.
Avatar
candide
Samuel Devulder a écrit :

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.




Tiens une girouette courageuse qui vient de tourner avec le vent !

Sinon, le degré zéro : ça marche chez moi donc c'est bon ! La caricature
te conduit à raconter n'importe quoi.
Avatar
espie
In article <4b157a26$0$12471$,
candide wrote:
Samuel Devulder a écrit :

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.




Tiens une girouette courageuse qui vient de tourner avec le vent !

Sinon, le degré zéro : ça marche chez moi donc c'est bon ! La caricature
te conduit à raconter n'importe quoi.



Quelqu'un trouvait recemment que j'avais ete vulgaire a ton egard.
Je l'incite a regarder ton comportement. Tes petites piques incessantes
et mesquines finissent par lasser fortement...

Fais gaffe, tu es au bord du *plonk*.
Avatar
Alexandre Bacquart
candide wrote:
Marc Espie a écrit :
Il y a deux sortes de gens par ici: ceux qui programment, et ceux qui sont
la juste pour chercher la petite bete. Tu trouverais sans doute plus ton
bonheur sur comp.lang.std.c...




Non, justement pas lang mais comp.std.c ;)

Tu as raison, la programmation en C au sens du travail d'un programmeur
ne m'intéresse pas plus que ça, pour l'instant en tous cas. Ce qui
m'intéresse c'est pas de chercher la petite bête mais réfléchir à des
moyens plus efficaces d'apprendre le C (ou d'autres langages), qu'on
s'adresse à des débutants ou à des programmeurs ayant déjà une certaine
expérience. Je me réfère à la Norme parce qu'elle propose en général des
informations beaucoup plus précises voire plus cohérentes, lisibles et
didactiques que la majorité des sources d'information.

Et si tu m'/nous expliquais plutôt pourquoi il est tellement scandaleux
d'initialiser par défaut à zéro les variables automatiques ?



Parce-que ça rend déterministe le comportement d'un code qui devrait
être aléatoire d'après la norme :

int main()
{
int i;
printf("%d", i);
}

Si on veut avoir au moins une chance de détecter le problème, encore
faut-il que i ne soit pas initialisé à 0 par le compilateur.


--
Alex
Avatar
candide
Samuel Devulder a écrit :

Oui... mais pas se prendre la tête la dessus quand c'est pas l'essentiel
du propos, ni même le problème original de l'OP.




Ah bon tu l'as compris le problème original de l'OP ?



D'une part ca n'aide en
rien l'OP, mais en plus ca part souvent dans des digression a n'en plus
finir entre telle ou telle interprètation de la norme qui n'influence en
rien l'usage réél.




Il me semble que le PO a reçu toutes les explications nécessaires et le
recadrage qu'il fallait, après ça on peut discuter, si ça t'intéresse
pas tu lis pas et d'ailleurs en répondant tu participes au bruit,
n'est-ce pas ?



De toute facon pour les tests et le débug, moi je recommande de ne pas
se baser sur un environnement ou les choses ne sont pas reproductibles



on dirait du -ed-

(une saisie au clavier par exemple), et je préfère écrire les chaînes en
dur dans le code pour mettre au point le coeur de l'algo. Une fois ce



Absolument, c'est ce que j'ai toujours prôné.


dernier validé, et les tests proprement mis dans un code de test
unitaire (pour détecter des régressions), on peut y aller des milles et
unes façon de saisir les paramètres dans un prog C (entrée clavier,
utilisation arc/argv, lecture de socket, du port série, que sais-je
encore).




Absolument, c'est le deuxième étage de la fusée (bon, la fusée n'est
peut-être pas une bonne image ;) )




Le truc a faire, et c'est pareil avec des stagiaires: tu les laisses
galérer un peu et corriger le problème eux-meme.. Ils verront que c'est
difficile, mais c'est normal: "c'est le métier qui rentre".




Tu travailles dans l'armée ?


S'ils n'y
arrivent pas, tu jette un œil à leur code en leur disant de ré-écrire
telle ou telle partie "en faisant comme ca, cela marchera" et qu'ils
viennent t'expliquer la différence entre leur code et l'implémentation
que tu suggère pour voir s'ils ont compris le truc.




A vos ordres mon commandant





Il est connu qu'on apprends plus
de ses erreurs que du reste.




Ben oui et a bon chat bon rat



Oui: il faut leur laisser galèrer un peu, ca ne fait pas de mal et après
qu'ils ont compris leur douleur,





Rien de tels que les bonnes vieilles méthodes qui ont fait leur preuve.
Au bout de 20 ans, ils sauront peut-être enfin coder en C.





Mais bon, il ne faut pas oublier non plus qu'il y a de vrai
neu-neus dont on se demande pourquoi ils font ou veulent faire de
l'info. Bon pour eux, une seule solution: stage dans l'équipe de qualité
à exercer bêtement mais scrupuleusement des fiches de tests.. ce sera
moins dangereux pour tout le monde.. quoi que ;)




Sidérant.
Avatar
candide
Marc Espie a écrit :

Fais gaffe, tu es au bord du *plonk*.






Chiche !!
Avatar
Samuel Devulder
candide a écrit :
Samuel Devulder a écrit :

Oui... mais pas se prendre la tête la dessus quand c'est pas l'essentiel
du propos, ni même le problème original de l'OP.




Ah bon tu l'as compris le problème original de l'OP ?



Oui il me semble. Je lui ai même conseillé de dérouler son algo à la
main, loin de l'ordi pour comprendre pourquoi son prog semble boucler.
J'ai même insisté dans un autre message en lui disant qu'il y a
plusieurs façon de réaliser des boucles qui ne sont pas qu'une structure
syntaxique type for() ou while().


Il me semble que le PO a reçu toutes les explications nécessaires et le
recadrage qu'il fallait, après ça on peut discuter,



Non après cela il faut stopper le thread et en ouvrir un autre si on
veut causer d'un autre sujet plus proche de la norme dont se fiche l'OP.

Enfin c'est mon avis, et du reste le sujet du fil de discussion aurait
du changer depuis bien longtemps car à part boucler en rond, on ne parle
plus trop de la problématique de bouclage posée par bpascal123 à cette
profondeur de messages :)

<snip du reste qui n'a aucun, mais aucun rapport avec la choucroute>

sam.
Avatar
Samuel Devulder
candide a écrit :
Samuel Devulder a écrit :

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.




Tiens une girouette courageuse qui vient de tourner avec le vent !

Sinon, le degré zéro : ça marche chez moi donc c'est bon !




Non. Ca marche chez moi et pas chez les autres: c'est la définition d'un
bug et on corrige en regardant la norme si besoin, mais c'est rare car
souvent le raisonnement et le bon sens suffisent.

Ca marche en développement, en condition réele sur les bancs de tests,
le compilo ou le linter grognent, on nettoie les codes, on repasse les
tests, ca continue à marcher. Super! La vie est belle. Le C est facile
si on ne se prends pas la tête avec des dogmes mais qu'on utilise sa
tête à comprendre pourquoi ca marche pas et corriger en conséquence.

sam.
10 11 12 13 14