ben y a des fois sans les parenthese ca marche pas(rencontre en programmation win32, mais je ne sais plus quand, ca date. Compilateur Mingwin). Alors qu'avec les parenthese t'es sur de gagner.
Ha on parlait de C ??? pourquoi ça serait évident ?
Ben d'un côté, return n'est pas une fonction mais une instruction donc pas de parenthèse. De l'autre, il y a un contre-exemple : l'instruction if qui provoque une erreur sans les parenthèses.
Même si on regarde les normes (K&R, ANSI, ISO, machin), il y a la réalité du terrain :-)
Il faut voir ce que ton compilateur accepte et ce que les compilateurs cibles en cas de portabilité acceptent pour leur part.
Au moins avec Python, la syntaxe est claire : pas de parenthèses autour des instructions ;-) ok, j'arrête...
Ben dans le doute, met-les, apparemment y'a des compilateurs qui les réclament mais c'est vrai que c'est embêtant (pour rester poli) de ne pas savoir pourquoi.
Bah à mon avis, le vrai kernighan et ritchie (les créateurs du c), celui qui est implémenté à peu près partout requiert un return avec des parenthèses, comme le dit le journal en haut c'est pas sur que ce soit implémenté partout sans.
Y a d'autres exemples, pr le booléen
faut faire #define TRUE (1 == 1) comme ca, tu es sur que cela marche partout
ca apporte des gains en compatibilité, évidemment t'es pas sur que ca marche partout. Tout le monde ne compte pas en octal (dans les machines spécialisées par exemple, il y a des machines qui comptent en décimal)
Maintenant j'ai la flemme de trouver la doc qui confirme ce que je dis ...
Il ne me viendrait jamais a l'idée de faire "return (0)" et je pense que tous les compilo comprennent "return 0"
Par contre, c'est vrai que "return (A?x:y)" peut se défendre et pourrait bien être necéssaire avec certain compilos (je ne peux pas tester ici)
je suis de ton avis
return (0) est stupide et illisible
alors que return 0 c'est 'achement mieux
meme pour faire un truc genre (tire de mon projet actuel) :
return ogl->terrain->data[x+y*ogl->terrain->width].height;
je mettrais pas de parentheses ;)
J'avais un pote qui jouait a ca. Son truc a lui c'etait les boucles for, tout dans les parentheses du for.
Genre for(foo=[*type]init(x,y,z,truc(alpha)),if(*ptr=++foo) chose=bidule([char*] ptr-8),check[schmolls=new gizmo(chose)]){};
Ben il a pas reussi a me convaincre. Par contre pendant le temps ou on etait en binome j'ai reussi a le faire changer d'avis.
# Re: return(result);
Posté par Nap . Évalué à 2.
c'est grave docteur ?
[^] # De : Profezor Schutklein
Posté par Christophe . Évalué à 1.
--
comme quoi l'accent du professeur allemand c'est pas aussi marrant pas ecrit.
# Re: return(result);
Posté par Jerome Herman . Évalué à 1.
Donc parentheses pour moi.
Kha
# Re: return(result);
Posté par Ramso . Évalué à 4.
Ben d'un côté, return n'est pas une fonction mais une instruction donc pas de parenthèse. De l'autre, il y a un contre-exemple : l'instruction if qui provoque une erreur sans les parenthèses.
Même si on regarde les normes (K&R, ANSI, ISO, machin), il y a la réalité du terrain :-)
Il faut voir ce que ton compilateur accepte et ce que les compilateurs cibles en cas de portabilité acceptent pour leur part.
Au moins avec Python, la syntaxe est claire : pas de parenthèses autour des instructions ;-) ok, j'arrête...
Ben dans le doute, met-les, apparemment y'a des compilateurs qui les réclament mais c'est vrai que c'est embêtant (pour rester poli) de ne pas savoir pourquoi.
[^] # Re: return(result);
Posté par Christophe . Évalué à 3.
parce qu'on le C tous.
ok -->[]
sinon, merci pour le conseil (meme si c'est pas ce qui m'interessait dans le sujet ...)
# Re: return(result);
Posté par ours Ours (site web personnel) . Évalué à 1.
Y a d'autres exemples, pr le booléen
faut faire #define TRUE (1 == 1) comme ca, tu es sur que cela marche partout
ca apporte des gains en compatibilité, évidemment t'es pas sur que ca marche partout. Tout le monde ne compte pas en octal (dans les machines spécialisées par exemple, il y a des machines qui comptent en décimal)
Maintenant j'ai la flemme de trouver la doc qui confirme ce que je dis ...
[^] # Re: return(result);
Posté par Christophe . Évalué à 1.
je n'ai pasde K&R sous la main mais je suis a peu pres sur que non.
# Re: return(result);
Posté par newbix . Évalué à 2.
Il ne me viendrait jamais a l'idée de faire "return (0)" et je pense que tous les compilo comprennent "return 0"
Par contre, c'est vrai que "return (A?x:y)" peut se défendre et pourrait bien être necéssaire avec certain compilos (je ne peux pas tester ici)
[^] # Re: return(result);
Posté par samds . Évalué à 1.
return (0) est stupide et illisible
alors que return 0 c'est 'achement mieux
meme pour faire un truc genre (tire de mon projet actuel) :
return ogl->terrain->data[x+y*ogl->terrain->width].height;
je mettrais pas de parentheses ;)
[^] # Re: return(result);
Posté par Ramso . Évalué à 1.
excuse-moi mais je trouve ça pas vraiment stupide mais en tout cas illisible !
[^] # Re: return(result);
Posté par Christophe . Évalué à 2.
et je suis sur que c'est la seule ligne de ta fonction ;-)
[^] # Re: return(result);
Posté par Jerome Herman . Évalué à 1.
Genre for(foo=[*type]init(x,y,z,truc(alpha)),if(*ptr=++foo) chose=bidule([char*] ptr-8),check[schmolls=new gizmo(chose)]){};
Ben il a pas reussi a me convaincre. Par contre pendant le temps ou on etait en binome j'ai reussi a le faire changer d'avis.
Kha
2 mois d'obfuscate code contest quand meme...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.