In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
la syntaxe : for (e1;e2;e3) { s; }
se traduit par : e1; while (e2) { s; e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Dans ton cas, il me semblerait préférable soit utiliser un while, ou un break commetu le fais ou alors (peut être plus standard) commencer par 0 (c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro. Le C ne présuppose rien dans une boucle for(). C'est le développeur qui fixe librement l'initialisation, le corps d'instructions et l'incrément.
Tu confonds avec les tableaux ou le premier élément est toujours tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier élément du tableau.
On notera que des language plus récents n'ont pas implanté de boucle "for" de cette manière (init, test, incrément) cela évite des erreurs et incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les standards peut poser problème.
-- Lionel Mychkine
In article <1lcaaok.jrawgx8riegjN%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
la syntaxe :
for (e1;e2;e3) { s; }
se traduit par :
e1;
while (e2) {
s;
e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc
d'instructions) et e3 (l'incrément de la variable) ne doivent pas être
exécutés. Tu commets la même erreur que Patrick.
Dans ton cas, il me semblerait préférable soit utiliser un while, ou un
break commetu le fais ou alors (peut être plus standard) commencer par 0
(c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro. Le C ne
présuppose rien dans une boucle for(). C'est le développeur qui fixe
librement l'initialisation, le corps d'instructions et l'incrément.
Tu confonds avec les tableaux ou le premier élément est toujours
tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par
zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier
élément du tableau.
On notera que des language plus récents n'ont pas implanté de boucle
"for" de cette manière (init, test, incrément) cela évite des erreurs et
incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les
standards peut poser problème.
In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
la syntaxe : for (e1;e2;e3) { s; }
se traduit par : e1; while (e2) { s; e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Dans ton cas, il me semblerait préférable soit utiliser un while, ou un break commetu le fais ou alors (peut être plus standard) commencer par 0 (c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro. Le C ne présuppose rien dans une boucle for(). C'est le développeur qui fixe librement l'initialisation, le corps d'instructions et l'incrément.
Tu confonds avec les tableaux ou le premier élément est toujours tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier élément du tableau.
On notera que des language plus récents n'ont pas implanté de boucle "for" de cette manière (init, test, incrément) cela évite des erreurs et incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les standards peut poser problème.
-- Lionel Mychkine
Patrick Stadelmann
In article , Lionel Mychkine wrote:
In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
> la syntaxe : > for (e1;e2;e3) { s; } > > se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1; e2;
s; e3; e2;
s; e3; e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte donc la boucle sur un test e2, test qui suit l'exécution de e3.
Patrick -- Patrick Stadelmann
In article <gZGdnW4jN-oSLR7PnZ2dnUVZ7rednZ2d@giganews.com>,
Lionel Mychkine <mychkine@nowhere.invalid> wrote:
In article <1lcaaok.jrawgx8riegjN%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
> la syntaxe :
> for (e1;e2;e3) { s; }
>
> se traduit par :
> e1;
> while (e2) {
> s;
> e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc
d'instructions) et e3 (l'incrément de la variable) ne doivent pas être
exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1;
e2;
s;
e3;
e2;
s;
e3;
e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte
donc la boucle sur un test e2, test qui suit l'exécution de e3.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
> la syntaxe : > for (e1;e2;e3) { s; } > > se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1; e2;
s; e3; e2;
s; e3; e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte donc la boucle sur un test e2, test qui suit l'exécution de e3.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article , Lionel Mychkine wrote:
In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
> la syntaxe : > for (e1;e2;e3) { s; } > > se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1; e2;
s; e3; e2;
s; e3; e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte donc la boucle sur un test e2, test qui *suit* l'exécution de e3.
Patrick -- Patrick Stadelmann
In article <gZGdnW4jN-oSLR7PnZ2dnUVZ7rednZ2d@giganews.com>,
Lionel Mychkine <mychkine@nowhere.invalid> wrote:
In article <1lcaaok.jrawgx8riegjN%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
> la syntaxe :
> for (e1;e2;e3) { s; }
>
> se traduit par :
> e1;
> while (e2) {
> s;
> e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc
d'instructions) et e3 (l'incrément de la variable) ne doivent pas être
exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1;
e2;
s;
e3;
e2;
s;
e3;
e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte
donc la boucle sur un test e2, test qui *suit* l'exécution de e3.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1lcaaok.jrawgx8riegjN%, (Pierre-Alain Dorange) wrote:
> la syntaxe : > for (e1;e2;e3) { s; } > > se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Non. La séquence est :
e1; e2;
s; e3; e2;
s; e3; e2;
...
Les lignes vides indiquent les sortie possibles de la boucle. On quitte donc la boucle sur un test e2, test qui *suit* l'exécution de e3.
Patrick -- Patrick Stadelmann
pdorange
Lionel Mychkine wrote:
> se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Je veux bien, mais avant qu'il y est erreur (e2) il faut que s soit exécuté. Donc pour reprendre ton exemple mono : La première boucle se passe bien : channel=1 err=0 channel++ (donc 2) La deuxi!me boucle commence (err est à ZERO) err=quelquechose channel++ (oui l'incrémentation a lieu en fin de boucle) Donc la troisième boucle ne démare pas et on a channel qui est à 3.
Je veux bien que l'on fasse tous la même erreur, mais c'est le fonctionnement normal.
> Dans ton cas, il me semblerait préférable soit utiliser un while, ou un > break commetu le fais ou alors (peut être plus standard) commencer par 0 > (c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro.
Il n'oblige pas, il est préférentiel. Les tableaux commencent à ZERO par exmple... leur première case esr donc tab[0] ; c'est tout.
Le C ne présuppose rien dans une boucle for(). C'est le développeur qui fixe librement l'initialisation, le corps d'instructions et l'incrément.
Oui et comme le définit le standard, * l'inititlisation (e1) est faite une fois au début * le test (e2) est évalué avant de commencer le cycle * l'incrémentation (e3) est réalisé à la FIN de CHAQUE cycle
Tu confonds avec les tableaux ou le premier élément est toujours tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier élément du tableau.
Bien sur que non, mais "naturellement" le langage C s'attend par défaut (mais on fait comme on veut bien sur) a ce que le premier élement soit ZERO.
> On notera que des language plus récents n'ont pas implanté de boucle > "for" de cette manière (init, test, incrément) cela évite des erreurs et > incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les standards peut poser problème.
Et bien on a pourtant un parfait exemple ici.
Je t'assuree essayes ton code sous Linux ou Windows, ou avec un autre compilateur ou lis bien les 2 liens envoyés plus haut.
Le comportement que tu décris est tout a fait normal et c'est l'implantation standard... Comment d'ailleurs pourvoir espérer pouvoir compiler le moindre source avec un bug pareil...
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Lionel Mychkine <mychkine@nowhere.invalid> wrote:
> se traduit par :
> e1;
> while (e2) {
> s;
> e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc
d'instructions) et e3 (l'incrément de la variable) ne doivent pas être
exécutés. Tu commets la même erreur que Patrick.
Je veux bien, mais avant qu'il y est erreur (e2) il faut que s soit
exécuté.
Donc pour reprendre ton exemple mono :
La première boucle se passe bien :
channel=1
err=0
channel++ (donc 2)
La deuxi!me boucle commence (err est à ZERO)
err=quelquechose
channel++ (oui l'incrémentation a lieu en fin de boucle)
Donc la troisième boucle ne démare pas et on a channel qui est à 3.
Je veux bien que l'on fasse tous la même erreur, mais c'est le
fonctionnement normal.
> Dans ton cas, il me semblerait préférable soit utiliser un while, ou un
> break commetu le fais ou alors (peut être plus standard) commencer par 0
> (c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro.
Il n'oblige pas, il est préférentiel. Les tableaux commencent à ZERO par
exmple... leur première case esr donc tab[0] ; c'est tout.
Le C ne
présuppose rien dans une boucle for(). C'est le développeur qui fixe
librement l'initialisation, le corps d'instructions et l'incrément.
Oui et comme le définit le standard,
* l'inititlisation (e1) est faite une fois au début
* le test (e2) est évalué avant de commencer le cycle
* l'incrémentation (e3) est réalisé à la FIN de CHAQUE cycle
Tu confonds avec les tableaux ou le premier élément est toujours
tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par
zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier
élément du tableau.
Bien sur que non, mais "naturellement" le langage C s'attend par défaut
(mais on fait comme on veut bien sur) a ce que le premier élement soit
ZERO.
> On notera que des language plus récents n'ont pas implanté de boucle
> "for" de cette manière (init, test, incrément) cela évite des erreurs et
> incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les
standards peut poser problème.
Et bien on a pourtant un parfait exemple ici.
Je t'assuree essayes ton code sous Linux ou Windows, ou avec un autre
compilateur ou lis bien les 2 liens envoyés plus haut.
Le comportement que tu décris est tout a fait normal et c'est
l'implantation standard... Comment d'ailleurs pourvoir espérer pouvoir
compiler le moindre source avec un bug pareil...
> se traduit par : > e1; > while (e2) { > s; > e3; }
On est bien d'accord. while(e2) donc si le test e2 est faux, s (le bloc d'instructions) et e3 (l'incrément de la variable) ne doivent pas être exécutés. Tu commets la même erreur que Patrick.
Je veux bien, mais avant qu'il y est erreur (e2) il faut que s soit exécuté. Donc pour reprendre ton exemple mono : La première boucle se passe bien : channel=1 err=0 channel++ (donc 2) La deuxi!me boucle commence (err est à ZERO) err=quelquechose channel++ (oui l'incrémentation a lieu en fin de boucle) Donc la troisième boucle ne démare pas et on a channel qui est à 3.
Je veux bien que l'on fasse tous la même erreur, mais c'est le fonctionnement normal.
> Dans ton cas, il me semblerait préférable soit utiliser un while, ou un > break commetu le fais ou alors (peut être plus standard) commencer par 0 > (c'est pas pour rien que le C a comme référence de base 0) :
Je ne vois pas en quoi le C oblige à commencer par zéro.
Il n'oblige pas, il est préférentiel. Les tableaux commencent à ZERO par exmple... leur première case esr donc tab[0] ; c'est tout.
Le C ne présuppose rien dans une boucle for(). C'est le développeur qui fixe librement l'initialisation, le corps d'instructions et l'incrément.
Oui et comme le définit le standard, * l'inititlisation (e1) est faite une fois au début * le test (e2) est évalué avant de commencer le cycle * l'incrémentation (e3) est réalisé à la FIN de CHAQUE cycle
Tu confonds avec les tableaux ou le premier élément est toujours tableau[0]. Donc ça fait sens a priori dans une boucle de commencer par zéro. Mais là encore le C ne t'oblige jamais à commencer par le premier élément du tableau.
Bien sur que non, mais "naturellement" le langage C s'attend par défaut (mais on fait comme on veut bien sur) a ce que le premier élement soit ZERO.
> On notera que des language plus récents n'ont pas implanté de boucle > "for" de cette manière (init, test, incrément) cela évite des erreurs et > incompréhensions (je pense au python par exemple).
Je ne vois pas en quoi l'utilisation d'une boucle for() respectant les standards peut poser problème.
Et bien on a pourtant un parfait exemple ici.
Je t'assuree essayes ton code sous Linux ou Windows, ou avec un autre compilateur ou lis bien les 2 liens envoyés plus haut.
Le comportement que tu décris est tout a fait normal et c'est l'implantation standard... Comment d'ailleurs pourvoir espérer pouvoir compiler le moindre source avec un bug pareil...
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Lionel Mychkine
In article , Patrick Stadelmann wrote:
s; e3; e2;
Le diable se cache dans les détails ;-)
Mais il faut reconnaître que le groupe fr.comp.sys.mac.programmation n'a jamais été aussi actif qu'aujourd'hui ! On se croirait revenu à l'époque d'avant Cocoa.
-- Lionel Mychkine
In article
<Patrick.Stadelmann-26A482.18144613112013@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
s;
e3;
e2;
Le diable se cache dans les détails ;-)
Mais il faut reconnaître que le groupe fr.comp.sys.mac.programmation n'a
jamais été aussi actif qu'aujourd'hui ! On se croirait revenu à l'époque
d'avant Cocoa.
Mais il faut reconnaître que le groupe fr.comp.sys.mac.programmation n'a jamais été aussi actif qu'aujourd'hui ! On se croirait revenu à l'époque d'avant Cocoa.
