Donc après tu mets ce que tu veux dans la condition du for. Tu peux aussi ne pas mettre d'initialisation. Tu peux aussi mettre plusieurs "last-actions" (comme je les appelle ici) en les séparant par des virgules... [tt]for( ; i<max && j<max && k<max ; i++,j++,k++)[/tt] bon c'est pas pratique courante mais c'est faisable quoi.
Ouais, mais mettre une condition de plus dans chaque for, ça rend le code plus lent (d'au moins 3 ns) ::). Enfin, c'est surtout que ça me paraà®t moins lisible (comment ça je suis de mauvaise foi ?), et remarquez qu'on est obligé d'exécuter le code qui se trouve après l'accolade de fermeture du for. (mais il n'y en a certes pas dans l'exemple donné ici).
Enfin, c'est surtout que ça me paraà®t moins lisible (comment ça je suis de mauvaise foi ?)
Ben en mm temps ça dépend justement des gens ça... moi j'aime pas les GOTO surtout parce que ça fait des sauts dans le code et tu peux vite être baladé et envoyé à droite à gauche, plus haut puis plus bas puis un peu partout sans trop de logique, mais bon.
dans 1227291896:
et remarquez qu'on est obligé d'exécuter le code qui se trouve après l'accolade de fermeture du for. (mais il n'y en a certes pas dans l'exemple donné ici).
Heu ??? Là par contre oui tu es clairement de mauvaise foi !! :P Parce qu'avec un GOTO c'est exactement pareil, le code après le label est exécuté tout pareil !
Heu ??? Là par contre oui tu es clairement de mauvaise foi !! :P Parce qu'avec un GOTO c'est exactement pareil, le code après le label est exécuté tout pareil !
Bah heureusement que le code après le label du goto est exécuté ! C'est ce qu'on lui demande de faire. Non le code gênant c'est celui entre l'accolade fermante et le label, mais aussi entre l'instruction goto elle-même et le code qui est après.
Ben en mm temps ça dépend justement des gens ça... moi j'aime pas les GOTO surtout parce que ça fait des sauts dans le code et tu peux vite être baladé et envoyé à droite à gauche, plus haut puis plus bas puis un peu partout sans trop de logique, mais bon.
Je propose la synthèse : • Oui à une instruction de branchement localisée (return, break, continue, goto) non ambigà¼e, quand c'est une solution plus claire que les autres. • Non au bordel.
Et pour fêter cela je propose une tournée générale :kicking:
PS : Je vais bientôt remplacer Martine ou Ségolène avec des phrases comme ça ..
Réponses
est équivalent à Donc après tu mets ce que tu veux dans la condition du for. Tu peux aussi ne pas mettre d'initialisation. Tu peux aussi mettre plusieurs "last-actions" (comme je les appelle ici) en les séparant par des virgules... [tt]for( ; i<max && j<max && k<max ; i++,j++,k++)[/tt] bon c'est pas pratique courante mais c'est faisable quoi.
Enfin, c'est surtout que ça me paraà®t moins lisible (comment ça je suis de mauvaise foi ?), et remarquez qu'on est obligé d'exécuter le code qui se trouve après l'accolade de fermeture du for. (mais il n'y en a certes pas dans l'exemple donné ici).
Heu ??? Là par contre oui tu es clairement de mauvaise foi !!
Bah heureusement que le code après le label du goto est exécuté ! C'est ce qu'on lui demande de faire. Non le code gênant c'est celui entre l'accolade fermante et le label, mais aussi entre l'instruction goto elle-même et le code qui est après.
Par exemple avec ce code :
Tu n'as pas forcément envie que code 4 ou code 5 soit exécuté quand tu veux sortir de la boucle...
Je propose la synthèse :
• Oui à une instruction de branchement localisée (return, break, continue, goto) non ambigà¼e, quand c'est une solution plus claire que les autres.
• Non au bordel.
Et pour fêter cela je propose une tournée générale :kicking:
PS : Je vais bientôt remplacer Martine ou Ségolène avec des phrases comme ça ..