b=10; while(a=b) { b--; if(b==-10)break; } B goes from 10 to -10. In my world, the while-statement, a=b, should always be true (since the assigment always "goes well"). That is not the case. When the loop stops, b will have a value of 0.In my world, it should pass 0 and go all the way to -10, when the if-statement kicks in.Have I misunderstood something major? (Code tested in IE8 and Adobe Acrobat)
9 Réponses :
évidemment, si (0) est équivalent à si (faux). p>
Donc, si (A = B) n'est vrai que si B est égal à quelque chose qui deviendrait vrai si jeté à Boolean. P>
Donc, si dise A et B est le même type, il sera considéré comme vrai si B est non nulle. P>
Ce que je ne comprends pas, c'est pourquoi ce code? p>
(0 = 0) == 0 == false
0 est FALSY en JavaScript, a = B Renvoie 0 lorsque B atteint 0, JavaScript lit donc false. p>
une solution simple serait p> ou dans ce cas, en raison de la pause 0 code> est une valeur fausses,
0 == false code> est vrai, donc dès que b hits 0, puis a = b évalue à False et la boucle pause.
; code> instruction que vous pouvez simplement utiliser p> < Pré> xxx pré> p>
Est-ce que False est le terme officiel pour cela? Cela semble être un mot étrange à utiliser.
Falsy et Truthy sont des descriptions bien connues de la coercition de type à une valeur booléenne. J'hésiterais à dire "officiel".
@baultista: "faux" i> est un terme maquillé qui est largement utilisé autour du débordement de pile, en particulier dans des questions pour des langages dynamiquement typés comme JS :-)
Oui, car la valeur de l'affectation est la valeur de l'expression attribuée. Qui est 0, qui est évalué à false. P>
tandis que la boucle attend une condition I.e. tandis que (condition) et traite avec Quand vrai ou faux code>
Par conséquent, votre boucle ci-dessus se traduit par
tandis que (a) code> ergo la condition de la boucle est la valeur d'un. P>
A code> atteint 0, votre boucle pause. p>
La valeur d'une affectation est la valeur attribuée, de sorte que vous pouvez chaîner des affectations a = b = 2 code> par exemple, alors lorsque
b = 0 code>, la valeur de
a = b code> est 0. p>
+1 C'est la chose importante qui n'a pas été clarifiée dans la plupart des réponses. La "valeur" d'une opération d'affectation est la valeur attribuée, et non quelque chose qui indiquerait si l'opération "va bien".
La déclaration tandis que, A = B, devrait toujours être vraie (puisque l'affectation "va bien"). P> blockQuote>
Ce n'est généralement pas une bonne idée de penser à la valeur de retour comme confirmation du succès de l'opération. L'exécution continue de votre code est l'indication que la mission s'est bien déroulée. strong> p>
notamment, votre intuition est en fait
en arrière forte> à partir de la norme dans le script de shell UNIX, où 0 code> signifie
a-ok! code> et non-zéro indique un autre résultat. P>
Maintenant que des choses comme des exceptions peuvent être utilisées pour indiquer un problème dans l'exécution, il existe de meilleurs mécanismes à utiliser pour cela. P>
En fait, 0 = 0 vous donnera le résultat de 0 qui est interprété comme faux. En d'autres termes tandis que (0 = 0) est à peu près la même chose que (0) qui enfreint la boucle. P>
Oui, c'est un malentendu qu'une mission devrait évaluer intrinsèquement quelque chose de vérité.
@NPUP Tout va évaluer quelque chose de vérité, tout ce que vous voudrez peut-être que la vérité soit: D
En outre, en utilisant quelques espaces ici et il vous aidera à long terme:
si (b == -10) casse; code>
L'affectation évalue la valeur attribuée à la valeur attribuée. (A = 4) est identique à ce que 4. A = 0 est identique à 0, et 0 est identique à faux.