Logiques ET, OU: Est de gauche à droite de l'évaluation de la garantie?

Est de gauche à droite de l'évaluation des opérateurs logiques (&& ||) garanti?

Disons que j'ai ceci:

SDL_Event event;

if (SDL_PollEvent(&event)) {
    if (event.type == SDL_QUIT) {
            //do stuff
    }
}

Est-ce garanti d'être le même que celui de la?

SDL_Event event;

if (SDL_PollEvent(&event) && event.type == SDL_QUIT) {
    //do stuff
}

Cela peut aussi être très important, disons que nous avons deux exigences, a et b. Exigence a est beaucoup plus susceptible d'échouer alors b. Ensuite, il est plus efficace de dire if (a && b) que if (b && a).

  • Un classique, l'utilisation importante pour le séquençage de l'implicite par && est de tester des pointeurs null avant de l'utiliser: if (a != 0 && a->b != 0 && a->b->c != 0) { somefunc(a->b->c->d); }. La séquence est essentielle pour éviter les vidages mémoire. (Et je suis ignorant la Loi de Déméter pour l'application de l'exposition!)
  • Je l'ignore pour le but d'obtenir le travail fait!
  • Ce ne sont pas des opérateurs de comparaison.
InformationsquelleAutor orlp | 2011-04-15
  1. 42

    Oui, c'est la garantie, sinon ils perdraient beaucoup de leur utilité.

    Avis Important: ceci est valable seulement pour la builtin && et ||; si certains criminels surcharges, ils sont traités comme des "réguliers" surcharge des opérateurs binaires, donc dans ce cas les deux opérandes sont toujours évalué, et dans un ordre non spécifié comme d'habitude. Pour cette raison, ne surchargez jamais les pauses d'un très important hypothèse sur le flux de contrôle du programme.

    Norme pertinente citations

    Builtin && et || avoir la garantie d'un court-circuit comportement

    §5.14 ¶1

    Contrairement à &, && garanties de gauche à droite de l'évaluation: le deuxième opérande n'est pas évalué si le premier opérande est false.

    §5.15 ¶1

    Contrairement à |, || garanties de gauche à droite de l'évaluation; de plus, le deuxième opérande n'est pas évalué si le premier opérande est évaluée à true.

    En cas de surcharge, ils se comportent comme des "réguliers" des opérateurs binaires (pas de court-circuit ou de la garantie de la commande de l'évaluation)

    §13.5 ¶9

    Les opérateurs ne sont pas mentionnés explicitement dans les sous-alinéas 13.5.3 par 13.5.7 loi ordinaire, les opérateurs unaires et binaires et obéir aux règles de 13.5.1 ou 13.5.2.

    et && et || ne sont pas explicitement mentionnés dans ces paragraphes, de manière régulière §13.5.2 détient:

    §13.5.2 ¶1

    Un opérateur binaire doit être mis en œuvre, soit par un non-fonction membre statique (9.3) avec un paramètre ou par un non-membre de la fonction avec deux paramètres. Ainsi, pour tout opérateur binaire @, x@y peut être interprété
    comme x.operator@(y) ou operator@(x,y).

    avec pas de disposition particulière pour l'évaluation d'un seul côté ou dans un ordre particulier.

    (toutes les citations de C++11)

    • Par le chemin, gardez à l'esprit que, si vous avez un "simple" conditions (par exemple, votre second) ramification peut coûter plus cher que l'évaluation de l'état lui-même.
    • Matteo Italia: a et b étaient hypothétiques. Ils pourraient avoir été IsPrime(n) et IsEven(n), dans lequel l'ordre est assez évident et grave des économies peuvent être faites.
    • assurez-vous, je viens de le souligner, mais une petite idée fausse commune. 🙂
    • Conditions, sans effets secondaires peuvent être déplacés n'importe où le compilateur aime. Le compilateur est autorisé à éliminer une branche.
    • c'est très important de noter que si vous remplacez operator&& ou operator|| puis il est traité comme un appel de fonction, et la gauche-à-droite de l'évaluation n'est plus garantie.[
    • yep, c'est vraiment important, en effet; ajout de la remarque et la référence des citations.

    InformationsquelleAutor Matteo Italia