Pourquoi pour (;;) traité comme une boucle infinie tandis que tandis que () donne une erreur car elle nécessite une expression? Pourquoi ne pas pour Les boucles attendent des expressions?
3 Réponses :
Disclaimer: Cette réponse explique pourquoi la syntaxe est valide et non pourquoi elle a été conçue de cette façon.
Selon le Documentation (met l'accent sur la mine):
Syntaxe formelle:
attr (facultatif) pour (condition de déclaration init ( en option ); itération_expression ( facultatif )) énoncé
Donc tout ce qui est requis est le
init-instruction et un; . Et pour leinit-instruction , il dit:Une déclaration d'expression (
qui peut être une déclaration nulle ";" ) Ainsi, si vous laissez les choses optionnelles et mettez un
; pour la déclaration init, tout ce que vous obtenez est;; . .dans C C'est un peu différent:
pour (init_clause; cond_expression; itération_expression) loop_statement
init_clause, cond_expression et iteration_expression sont tous facultatifs
C'est les deux
; et trois clauses / expressions facultatives. Si vous omettez tous les trois, vous obtenez;; à nouveau.
Je pense que la question est pourquoi (si je ne dis pas que ma tentative de répondre à cette question est incroyable)
Vous avez raison. Il y a une certaine ambiguïté ici. Il pourrait être interprété comme "pourquoi est-ce comme ça" ou comme "pourquoi les règles ont-elles défini-la comme ceci".
Voir, j'interprèterais les deux déclarations de la même manière: P comme l'OP a déjà découvert que la langue permet à la langue et non à l'autre et à la reformulation de cette observation en normes n'ajoute pas vraiment à notre compréhension :)
Vrai que. La façon dont je l'ai interprétée, je pensais que OP voulait savoir s'il y a une supercheuse syntaxique qui permet d'omettre la déclaration dans pour d'être omise, mais ne fonctionne pas dans pendant . Quoi qu'il en soit, j'apprécie votre réponse à la question de l'OP, je n'y ai jamais pensé beaucoup mais maintenant je sais. :)
Ce n'est que ... pas.
En fin de compte, il n'y a pas de raison impérieuse de permettre une condition vide dans pour symétrie avec Ce sont des caractéristiques linguistiques différentes et il n'y a pas de raison forte de leur faire fonctionner de la même manière à cet égard aux dépens d'autres considérations. tandis que aurait pu être effectué pour permettre une condition vide (qui serait probablement interprété comme vrai ), mais il serait alors asymétrique avec si pour lequel cela aurait moins de sens.
pendant que préambule, car tout code utilisant cela ne serait pas auto-documentant.
pour , vous pouvez avoir besoin pour (; vrai;) - sauf que cela a l'air bizarre, car les clauses de déclaration et de mise à jour peuvent maintenant être vides alors que la condition ne peut pas. D'accord, faisons ces obligatoires aussi. Alors, que mettons-nous dans ces endroits pour No-Ops? pour (int manneau = 0; vrai; (vide) mannequin) ? Maintenant, ça devient idiot.
Nice Expl. Remarque: "Pour être plus précis, pourquoi pour la boucle ne s'attend pas à une expression [?]" -> eel.is/c++draft/stmt.for#2 je suppose
Il s'agit d'une question de conception linguistique, alors les concepteurs de langue devraient choisir. Mon avis: Les fonctionnalités optionnelles (spécialement raccourcis) d'une langue devraient Empêcher les erreurs. Donc, tandis que () est facilement une erreur (vous avez omis le conditionnel, par exemple 0 ou 1), tandis que pour (;;) est rarement une erreur (vous devez consciemment le type 2;).
Mm ouais c'est une bonne raison de ne pas vous inquiéter de l'asymétrie 👍
Et les réponses telles que ceci sont précisément pourquoi la question est principalement basée sur une opinion et devrait être fermée en tant que telle. Cette réponse exprime une opinion valide et une explication plausible, mais ce n'est toujours qu'un avis.
@Johnbollinger i pense Nous avons eu tendance à permettre "Pourquoi x a-t-il été conçu de cette manière" car les raisons sont souvent objectivement déterminées de sources contemporaines ou de rapports de concepteurs de langues qui ont des raisons pratiques que nous n'avons peut-être pas envisagées. Le choix lui-même peut avoir été subjectif mais nous pouvons généralement signaler ces raisons objectivement. (Cela contraste avec les questions de type de style de code qui sont subjectives au point de vente, et c'est ce que la règle est conçue pour éliminer.) Bien que dans ce cas, je ne suis pas sûr de la justification, si jamais existait vraiment, est découvrable. .
@Lightness, je ferais bien une réponse qui fournit la justification réelle de Kernighan et de Ritchie pour ce choix de conception, voire une analyse de la conception linguistique du temps qui produit une conclusion tierce sur une telle justification. Mais cette question particulière semble peu probable de céder une telle réponse, et nous sommes laissés dans la situation exactement que la principale raison de «principalement basée sur l'opinion» est censée sortir.
@Johnbollinger Eh bien, vous ne savez pas avant de vous demander;) J'ai vu beaucoup de questions comme celle-ci où une telle réponse est disponible. "Nous ne savons pas" est une réponse valide autrement. Je pense toujours que cela laisse la question sur le sujet, car ce n'est pas, en soi, solliciter des conseils ou des opinions sur des questions subjectives.
Pas besoin de ré-taguer. Une bonne réponse C ++ entrera dans une profondeur aussi de profondeur qu'une réponse C.
Via max, celles-ci sont probablement dupes TBF stackoverflow.com/questions/13146830/... Stackoverflow.com/questions/13366290/... (particulièrement que la dernière)
De plus, cela pourrait être déroutant. Pour moi,
tandis que () ressemble àtandis que (false) outandis que (null) , pastandis que (vrai) >.