Pourquoi utiliser une affectation dans une condition?

Question

Dans de nombreuses langues, les affectations sont légales dans des conditions. Je n'ai jamais compris la raison derrière cela. Pourquoi voudriez-vous écrire:

if (var1 = var2) { 
    ... 
} 

au lieu de:

var1 = var2; 
if (var1) { 
    ... 
} 

Answer 1

Il est plus utile pour les boucles que pour les instructions.

while(var = GetNext()) 
{ 
    ...do something with var 
} 

qui autrement aurait à écrire

var = GetNext(); 
while(var) 
{ 
...do something 
var = GetNext(); 
} 

Answer 2

Il peut être utile si vous appelez une fonction qui renvoie soit des données pour travailler sur ou un drapeau pour indiquer une erreur (ou que vous avez terminé).

Quelque chose comme:

while ((c = getchar()) != EOF) { 
    // process the character 
} 

// end of file reached... 

Personnellement c'est un idiome que je ne suis pas extrêmement friand, mais parfois l'alternative est plus laid.

Answer 3

Il est plus utile si vous appelez une fonction:

if (n = foo()) 
{ 
    /* foo returned a non-zero value, do something with the return value */ 
} else { 
    /* foo returned zero, do something else */ 
} 

Bien sûr, vous pouvez simplement mettre le n = foo(); sur une déclaration séparée alors si (n), mais je pense que ce qui précède est un idiome assez lisible.

Answer 4

L'idiome est plus utile lorsque vous écrivez une boucle while au lieu d'une instruction if. Pour une instruction if, vous pouvez la décomposer comme vous l'avez décrit. Mais sans cette construction, vous devez soit vous répéter:

c = getchar(); 
while (c != EOF) { 
    // ... 
    c = getchar(); 
} 

ou utiliser une structure en boucle et demi:

while (true) { 
    c = getchar(); 
    if (c == EOF) break; 
    // ... 
} 

Je préfère habituellement la boucle et-a- demi forme.

Answer 5

GCC peut vous aider à détecter (avec -Wall) si vous essayez involontairement d'utiliser une assignation en tant que valeur de la vérité, dans le cas où il vous recommande d'écrire

if ((n = foo())) { 
    ... 
} 

à savoir utilisez des parenthèses supplémentaires pour indiquer que c'est vraiment ce que vous voulez.

Answer 6

En PHP, par exemple, il est utile pour une boucle à travers les résultats de la base de données SQL:

while ($row = mysql_fetch_assoc($result)) { 
    // Display row 
} 

Cela ressemble beaucoup mieux que:

$row = mysql_fetch_assoc($result); 
while ($row) { 
    // Display row 
    $row = mysql_fetch_assoc($result); 
} 

Answer 7

Je trouve cela très utile dans les chaînes d'actions qui impliquent souvent la détection d'erreurs, etc.

if ((rc = first_check(arg1, arg2)) != 0) 
{ 
    report error based on rc 
} 
else if ((rc = second_check(arg2, arg3)) != 0) 
{ 
    report error based on new rc 
} 
else if ((rc = third_check(arg3, arg4)) != 0) 
{ 
    report error based on new rc 
} 
else 
{ 
    do what you really wanted to do 
} 

L'alternative (ne pas utiliser l'affectation dans l'état) est:

rc = first_check(arg1, arg2); 
if (rc != 0) 
{ 
    report error based on rc 
} 
else 
{ 
    rc = second_check(arg2, arg3); 
    if (rc != 0) 
    { 
     report error based on new rc 
    } 
    else 
    { 
     rc = third_check(arg3, arg4); 
     if (rc != 0) 
     { 
      report error based on new rc 
     } 
     else 
     { 
      do what you really wanted to do 
     } 
    } 
} 

Avec vérification d'erreur prolongée, l'alternative peut ruisseler l'ERS de la page alors que la cession en conditionnelle Version ne fait pas ça.

Answer 8

La réponse courte est que Expression-oriented les langages de programmation permettent un code plus succinct. Le ne vous force pas à separate commands from queries.

Answer 9

L'autre avantage vient pendant l'utilisation de gdb. Dans le code suivant, le code d'erreur n'est pas connu si nous devions effectuer une seule étape.

while (checkstatus() != -1) { 
    // process 
} 

plutôt

while (true) { 
    int error = checkstatus(); 
    if (error != -1) 
     // process 
    else 
     //fail 
} 

Maintenant, lors de l'étape unique, nous pouvons savoir ce qui était le code d'erreur de retour de la checkStatus().

Answer 10

La raison en est:

1. Amélioration de la performance (parfois)

2. code Lesser (toujours)

Prenons un exemple: Il existe une méthode someMethod() et dans un if condition que vous voulez vérifier si la valeur de retour de la méthode est null. Sinon, vous allez utiliser la valeur de retour à nouveau.

If(null != someMethod()){ 
    String s = someMethod(); 
    ...... 
    //Use s 
} 

Cela entravera les performances car vous appelez deux fois la même méthode. Au lieu d'utiliser:

String s; 
If(null != (s = someMethod())) { 
    ...... 
    //Use s 
}