J'ai des pb bizarres : dans une fonction j'ai besoin que l'utilisateur
me donne plusieurs infos, je fais donc des printf("question") et des scanf.
Sur les 3 premieres questions, ca marche bien, sur les 2 dernières, le
programme les affiche, mais le scanf ne semble pas marcher. Pourtant le
scanf recup sur les 5 fois un char *. C'est un bug? D'ailleurs si je ne
mets pas de \n sur le printf, parfois c'est encore pire...
voici un ex :
char *nom;
printf("nom\n");
scanf("%s", nom);
etc .. prenom, adress, tel, mail...
Parfois le scanf est comme sauté. Dans une autre fonction, je fais la
meme chose : une question, une reponse. Il m'affiche bien la question,
mais le scanf comme s'il était inactif, le programme ne me laisse pas
répondre, et passe à l'instruction suivante...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Charlie Gordon
"Emmanuel Delahaye" wrote in message news:
Charlie Gordon wrote on 05/11/04 :
Il faut écrire :
while ((c = getc(fp)) != EOF && c!= 'n') continue;
le continue redondant est là pour éviter le statement vide, que je préfère ne jamais utiliser, en particulier sur la même ligne que le while ou le for.
Je mets
while ((c = getc(fp)) != EOF && c!= 'n') { }
En fait, je mets toujours les {}
Question de goût et surtout de conventions. Je ne mets pas les {} pour les if/for/while qui ne commandent qu'un statement simple d'une ligne. Comme c'est un peu risqué, je suis très strict quant au style général : jamais plus d'un statement par ligne, jamais de statements vides, jamais de {}, indentation et espacements strictement codifiés et imposés, constructions non standard interdites... Je mettrai tout cela en ligne un de ces 4.
Chqrlie.
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> wrote in message
news:mn.2c6a7d4baac35c26.15512@YOURBRAnoos.fr...
Charlie Gordon wrote on 05/11/04 :
Il faut écrire :
while ((c = getc(fp)) != EOF && c!= 'n')
continue;
le continue redondant est là pour éviter le statement vide, que je préfère
ne jamais utiliser, en particulier sur la même ligne que le while ou le for.
Je mets
while ((c = getc(fp)) != EOF && c!= 'n')
{
}
En fait, je mets toujours les {}
Question de goût et surtout de conventions.
Je ne mets pas les {} pour les if/for/while qui ne commandent qu'un statement
simple d'une ligne. Comme c'est un peu risqué, je suis très strict quant au
style général : jamais plus d'un statement par ligne, jamais de statements
vides, jamais de {}, indentation et espacements strictement codifiés et imposés,
constructions non standard interdites... Je mettrai tout cela en ligne un de
ces 4.
while ((c = getc(fp)) != EOF && c!= 'n') continue;
le continue redondant est là pour éviter le statement vide, que je préfère ne jamais utiliser, en particulier sur la même ligne que le while ou le for.
Je mets
while ((c = getc(fp)) != EOF && c!= 'n') { }
En fait, je mets toujours les {}
Question de goût et surtout de conventions. Je ne mets pas les {} pour les if/for/while qui ne commandent qu'un statement simple d'une ligne. Comme c'est un peu risqué, je suis très strict quant au style général : jamais plus d'un statement par ligne, jamais de statements vides, jamais de {}, indentation et espacements strictement codifiés et imposés, constructions non standard interdites... Je mettrai tout cela en ligne un de ces 4.
Chqrlie.
Charlie Gordon
"Jean-Marc Bourguet" wrote in message news:
Laurent Deniau writes:
Je suis d'accord que ca aurait put etre mieux pense. Mais cela doit tout de meme etre pratique pour que C++ (Boost) et Java (PrintStream) cherchent a refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-) Mettre les paramètres dans un ordre différent selon les langues n'est permis que par une extension de la glibc qui n'est pas particulièrement élégante et dont l'implémentation, que j'ai cru devoir me cogner dans une libc perso, est vraiment sordide.
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation. En plus leur surcharge abusive des << rend le code totalement illisible, en particulier quand on veut exercer un minimum de contrôle sur le formatage. L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus... Bref printf, qui trouve ses racines directement dans le FORTRAN est encore un moindre mal, mais pas très plaisant il faut bien reconnaitre.
Chqrlie.
PS: anglais amusant : langue se traduit par 'tongue' (prononcer comme les sandales, même origine ;-) dans la plupart des contextes : langues étrangères -> 'foreign tongues', langue maternelle -> 'mother tongue' ! incroyable n'est-ce pas.
"Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
news:pxbu0s4ti2a.fsf@news.bourguet.org...
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Je suis d'accord que ca aurait put etre mieux pense. Mais cela doit tout de
meme etre pratique pour que C++ (Boost) et Java (PrintStream) cherchent a
refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation des formats est
l'internationalisation et la possibilite de mettre les parametres dans
des ordres differents suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-)
Mettre les paramètres dans un ordre différent selon les langues n'est permis que
par une extension de la glibc qui n'est pas particulièrement élégante et dont
l'implémentation, que j'ai cru devoir me cogner dans une libc perso, est
vraiment sordide.
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément
impossible sans recompilation. En plus leur surcharge abusive des << rend le
code totalement illisible, en particulier quand on veut exercer un minimum de
contrôle sur le formatage. L'utilisation de + en javascript ne donne pas de
résultat satisfaisant non plus... Bref printf, qui trouve ses racines
directement dans le FORTRAN est encore un moindre mal, mais pas très plaisant il
faut bien reconnaitre.
Chqrlie.
PS: anglais amusant : langue se traduit par 'tongue' (prononcer comme les
sandales, même origine ;-) dans la plupart des contextes : langues étrangères ->
'foreign tongues', langue maternelle -> 'mother tongue' ! incroyable n'est-ce
pas.
Je suis d'accord que ca aurait put etre mieux pense. Mais cela doit tout de meme etre pratique pour que C++ (Boost) et Java (PrintStream) cherchent a refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-) Mettre les paramètres dans un ordre différent selon les langues n'est permis que par une extension de la glibc qui n'est pas particulièrement élégante et dont l'implémentation, que j'ai cru devoir me cogner dans une libc perso, est vraiment sordide.
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation. En plus leur surcharge abusive des << rend le code totalement illisible, en particulier quand on veut exercer un minimum de contrôle sur le formatage. L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus... Bref printf, qui trouve ses racines directement dans le FORTRAN est encore un moindre mal, mais pas très plaisant il faut bien reconnaitre.
Chqrlie.
PS: anglais amusant : langue se traduit par 'tongue' (prononcer comme les sandales, même origine ;-) dans la plupart des contextes : langues étrangères -> 'foreign tongues', langue maternelle -> 'mother tongue' ! incroyable n'est-ce pas.
Charlie Gordon
"Antoine Leca" wrote in message news:cmg76c$d1p$
En cmfv8i$pqd$, Charlie Gordon va escriure:
Des données suffisamment bien travaillées permettront de faire faire à peu près n'importe quoi au programme qui execute ce code.
On s'en moque. En fait, au vu de cet exemple, le programmeur normal devrait être effrayé par la complexité de scanf et donc fuir, ce qui est plutôt sain, non ?
Alors "%49[012346789]" aurait encore mieux fait l'affaire ;-)
éventuellement "%49[0-9]".
Non légal.
Légal, mais la signification est implementation defined ! Les normateurs sont trop mous.
Conclusion : laisser tomber cette daube de scanf.
La daube, c'est bon. Et plus elle est élaborée, meilleur c'est. ;-)
OK : laisser tomber cette fiente de scanf... et je suis à court de vocabulaire non grossier pour gets ou strncpy ;-)
Chqrlie.
"Antoine Leca" <root@localhost.gov> wrote in message
news:cmg76c$d1p$1@shakotay.alphanet.ch...
En cmfv8i$pqd$1@reader1.imaginet.fr, Charlie Gordon va escriure:
Des données suffisamment bien travaillées permettront de faire
faire à peu près n'importe quoi au programme qui execute ce code.
On s'en moque. En fait, au vu de cet exemple, le programmeur normal devrait
être effrayé par la complexité de scanf et donc fuir, ce qui est plutôt
sain, non ?
Alors "%49[012346789]" aurait encore mieux fait l'affaire ;-)
éventuellement "%49[0-9]".
Non légal.
Légal, mais la signification est implementation defined ! Les normateurs sont
trop mous.
Conclusion : laisser tomber cette daube de scanf.
La daube, c'est bon. Et plus elle est élaborée, meilleur c'est. ;-)
OK : laisser tomber cette fiente de scanf... et je suis à court de vocabulaire
non grossier pour gets ou strncpy ;-)
Des données suffisamment bien travaillées permettront de faire faire à peu près n'importe quoi au programme qui execute ce code.
On s'en moque. En fait, au vu de cet exemple, le programmeur normal devrait être effrayé par la complexité de scanf et donc fuir, ce qui est plutôt sain, non ?
Alors "%49[012346789]" aurait encore mieux fait l'affaire ;-)
éventuellement "%49[0-9]".
Non légal.
Légal, mais la signification est implementation defined ! Les normateurs sont trop mous.
Conclusion : laisser tomber cette daube de scanf.
La daube, c'est bon. Et plus elle est élaborée, meilleur c'est. ;-)
OK : laisser tomber cette fiente de scanf... et je suis à court de vocabulaire non grossier pour gets ou strncpy ;-)
Chqrlie.
Charlie Gordon
"Richard Delorme" wrote in message news:418bca21$0$15756$
Il me semble qu'il y a des discussions pour utiliser %.*s, voire un autre opérateur symétrique avec printf.
[...]
Conclusion : laisser tomber cette daube de scanf.
Des gens pensent le contraire, et qu'il faut laisser tomber fgets() en faveur de scanf :
Dan Pop est très minoritaire sur ce point. Je suis plutôt d'accord avec PJ Plauger, dans ce thread. C'est quand même triste qu'il ait fallu attendre Microsoft pour aller dans la donne direction, alors même que les plus innocents d'entre nous supposent déjà que %.*s a cette signification par analogie avec printf !
Chqrlie.
"Richard Delorme" <abulmo@nospam.fr> wrote in message
news:418bca21$0$15756$7a628cd7@news.club-internet.fr...
Il me semble qu'il y a des discussions pour utiliser %.*s, voire un
autre opérateur symétrique avec printf.
[...]
Conclusion : laisser tomber cette daube de scanf.
Des gens pensent le contraire, et qu'il faut laisser tomber fgets() en
faveur de scanf :
Dan Pop est très minoritaire sur ce point.
Je suis plutôt d'accord avec PJ Plauger, dans ce thread.
C'est quand même triste qu'il ait fallu attendre Microsoft pour aller dans la
donne direction, alors même que les plus innocents d'entre nous supposent déjà
que %.*s a cette signification par analogie avec printf !
Dan Pop est très minoritaire sur ce point. Je suis plutôt d'accord avec PJ Plauger, dans ce thread. C'est quand même triste qu'il ait fallu attendre Microsoft pour aller dans la donne direction, alors même que les plus innocents d'entre nous supposent déjà que %.*s a cette signification par analogie avec printf !
Chqrlie.
Jean-Marc Bourguet
"Charlie Gordon" writes:
"Jean-Marc Bourguet" wrote in message news:
Laurent Deniau writes:
Je suis d'accord que ca aurait put etre mieux pense. Mais cela doit tout de meme etre pratique pour que C++ (Boost) et Java (PrintStream) cherchent a refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-)
Non. C'est l'intérêt principal que je vois à l'utilisation de formats.
Mettre les paramètres dans un ordre différent selon les langues n'est permis que par une extension de la glibc qui n'est pas particulièrement élégante et dont l'implémentation, que j'ai cru devoir me cogner dans une libc perso, est vraiment sordide.
C'est plus que du glibc, c'est POSIX (et c'est même XPG4).
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation. En plus leur surcharge abusive des << rend le code totalement illisible,
Non. C'est l'utilisation de << pour les shifts que je trouve illisible. Quand on a l'habitude du C++, << est d'abord l'opérateur d'affichage.
en particulier quand on veut exercer un minimum de contrôle sur le formatage. L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Charlie Gordon" <news@chqrlie.org> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
news:pxbu0s4ti2a.fsf@news.bourguet.org...
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Je suis d'accord que ca aurait put etre mieux
pense. Mais cela doit tout de meme etre pratique pour
que C++ (Boost) et Java (PrintStream) cherchent a
refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation
des formats est l'internationalisation et la possibilite
de mettre les parametres dans des ordres differents
suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-)
Non. C'est l'intérêt principal que je vois à l'utilisation
de formats.
Mettre les paramètres dans un ordre différent selon les
langues n'est permis que par une extension de la glibc qui
n'est pas particulièrement élégante et dont
l'implémentation, que j'ai cru devoir me cogner dans une
libc perso, est vraiment sordide.
C'est plus que du glibc, c'est POSIX (et c'est même XPG4).
Il est clair qu'en C++, le mécanisme des streams rend tout
cela carrément impossible sans recompilation. En plus
leur surcharge abusive des << rend le code totalement
illisible,
Non. C'est l'utilisation de << pour les shifts que je
trouve illisible. Quand on a l'habitude du C++, << est
d'abord l'opérateur d'affichage.
en particulier quand on veut exercer un minimum de
contrôle sur le formatage. L'utilisation de + en
javascript ne donne pas de résultat satisfaisant non
plus...
+ est clairement de l'abus.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je suis d'accord que ca aurait put etre mieux pense. Mais cela doit tout de meme etre pratique pour que C++ (Boost) et Java (PrintStream) cherchent a refaire la meme chose (en plus securise certes).
Pour les sorties, l'interet principal de l'utilisation des formats est l'internationalisation et la possibilite de mettre les parametres dans des ordres differents suivant les langages.
Tu plaisantes ? Je n'ai pas vu de ;-)
Non. C'est l'intérêt principal que je vois à l'utilisation de formats.
Mettre les paramètres dans un ordre différent selon les langues n'est permis que par une extension de la glibc qui n'est pas particulièrement élégante et dont l'implémentation, que j'ai cru devoir me cogner dans une libc perso, est vraiment sordide.
C'est plus que du glibc, c'est POSIX (et c'est même XPG4).
Il est clair qu'en C++, le mécanisme des streams rend tout cela carrément impossible sans recompilation. En plus leur surcharge abusive des << rend le code totalement illisible,
Non. C'est l'utilisation de << pour les shifts que je trouve illisible. Quand on a l'habitude du C++, << est d'abord l'opérateur d'affichage.
en particulier quand on veut exercer un minimum de contrôle sur le formatage. L'utilisation de + en javascript ne donne pas de résultat satisfaisant non plus...
+ est clairement de l'abus.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette
"Stephane Legras-Decussy" a écrit:
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait. J'aime bien l'idée du "tout carré sauf": if(condition)action; L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan. -- Pierre
"Stephane Legras-Decussy" <1455yYUn25GH@JK456-huueGH> a écrit:
Charlie Gordon <news@chqrlie.org> a écrit dans le message :
cmiitn$9rt$1@reader1.imaginet.fr...
Je mettrai tout cela en ligne un de
ces 4.
je bookmark d'avance...
Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par
"instruction", ce sera parfait.
J'aime bien l'idée du "tout carré sauf":
if(condition)action;
L'éditeur de C++BuilderX (issu directement de JBuilder) est assez
pratique sur ce plan.
--
Pierre
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait. J'aime bien l'idée du "tout carré sauf": if(condition)action; L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan. -- Pierre
Stephane Legras-Decussy
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance...
Charlie Gordon <news@chqrlie.org> a écrit dans le message :
cmiitn$9rt$1@reader1.imaginet.fr...
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance...
Charlie Gordon
"Pierre Maurette" wrote in message news:
"Stephane Legras-Decussy" a écrit:
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont rédigées en anglais.
J'aime bien l'idée du "tout carré sauf": if(condition)action; L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan.
Je ne suis pas sûr de comprendre. J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans les cas ou (condition) et action tiennent sont simples et en particulier tiennent chacun sur une ligne.
Chqrlie.
"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:dusqo019ur31b1q4m2qhem9h1uschtde1r@4ax.com...
"Stephane Legras-Decussy" <1455yYUn25GH@JK456-huueGH> a écrit:
Charlie Gordon <news@chqrlie.org> a écrit dans le message :
cmiitn$9rt$1@reader1.imaginet.fr...
Je mettrai tout cela en ligne un de
ces 4.
je bookmark d'avance...
Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par
"instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont
rédigées en anglais.
J'aime bien l'idée du "tout carré sauf":
if(condition)action;
L'éditeur de C++BuilderX (issu directement de JBuilder) est assez
pratique sur ce plan.
Je ne suis pas sûr de comprendre.
J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans
les cas ou (condition) et action tiennent sont simples et en particulier
tiennent chacun sur une ligne.
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont rédigées en anglais.
J'aime bien l'idée du "tout carré sauf": if(condition)action; L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan.
Je ne suis pas sûr de comprendre. J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans les cas ou (condition) et action tiennent sont simples et en particulier tiennent chacun sur une ligne.
Chqrlie.
Pierre Maurette
"Charlie Gordon" a écrit:
"Pierre Maurette" wrote in message news:
"Stephane Legras-Decussy" a écrit:
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont rédigées en anglais. Dans ce cas ....
J'aime bien l'idée du "tout carré sauf": if(condition)action;
L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan.
Je ne suis pas sûr de comprendre. J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans les cas ou (condition) et action tiennent sont simples et en particulier tiennent chacun sur une ligne. C'est moi qui avais mal compris.
Je n'omets les {} que quand j'ai: if(condition)action; C'est vrai que j'utilise cette forme alors que l'opérateur ternaire irait bien. J'y viens peu à peu. Je ne suis pas cohérent pour l'instant. Des fois j'enfonce le clou avec: for(action;condition;action){}; Je n'aime pas les for() bricolés à coup d'opérateur virgule. Et puis des fois, je fais n'importe quoi pour améliorer le pas à pas ou pour avoir des messages d'erreur plus explicites. -- Pierre
"Charlie Gordon" <news@chqrlie.org> a écrit:
"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:dusqo019ur31b1q4m2qhem9h1uschtde1r@4ax.com...
"Stephane Legras-Decussy" <1455yYUn25GH@JK456-huueGH> a écrit:
Charlie Gordon <news@chqrlie.org> a écrit dans le message :
cmiitn$9rt$1@reader1.imaginet.fr...
Je mettrai tout cela en ligne un de
ces 4.
je bookmark d'avance...
Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par
"instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont
rédigées en anglais.
Dans ce cas ....
J'aime bien l'idée du "tout carré sauf":
if(condition)action;
L'éditeur de C++BuilderX (issu directement de JBuilder) est assez
pratique sur ce plan.
Je ne suis pas sûr de comprendre.
J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans
les cas ou (condition) et action tiennent sont simples et en particulier
tiennent chacun sur une ligne.
C'est moi qui avais mal compris.
Je n'omets les {} que quand j'ai:
if(condition)action;
C'est vrai que j'utilise cette forme alors que l'opérateur ternaire
irait bien. J'y viens peu à peu.
Je ne suis pas cohérent pour l'instant. Des fois j'enfonce le clou
avec:
for(action;condition;action){};
Je n'aime pas les for() bricolés à coup d'opérateur virgule.
Et puis des fois, je fais n'importe quoi pour améliorer le pas à pas
ou pour avoir des messages d'erreur plus explicites.
--
Pierre
Charlie Gordon a écrit dans le message : cmiitn$9rt$
Je mettrai tout cela en ligne un de ces 4.
je bookmark d'avance... Je m'inscris également.
Si en plus le [futur] texte de Charlie peut remplacer "statement" par "instruction", ce sera parfait.
Ben il faudra que tu fasses la traduction complète alors, mes conventions sont rédigées en anglais. Dans ce cas ....
J'aime bien l'idée du "tout carré sauf": if(condition)action;
L'éditeur de C++BuilderX (issu directement de JBuilder) est assez pratique sur ce plan.
Je ne suis pas sûr de comprendre. J'interdis les if /for/while en une seule ligne, et je n'omets les {} que dans les cas ou (condition) et action tiennent sont simples et en particulier tiennent chacun sur une ligne. C'est moi qui avais mal compris.
Je n'omets les {} que quand j'ai: if(condition)action; C'est vrai que j'utilise cette forme alors que l'opérateur ternaire irait bien. J'y viens peu à peu. Je ne suis pas cohérent pour l'instant. Des fois j'enfonce le clou avec: for(action;condition;action){}; Je n'aime pas les for() bricolés à coup d'opérateur virgule. Et puis des fois, je fais n'importe quoi pour améliorer le pas à pas ou pour avoir des messages d'erreur plus explicites. -- Pierre
