10
votes

Est & = garantie de se comporter comme hypothétique && = opérateur?

Parfois, je voudrais faire

bool success= true;
success &&= dosmthing1();
success &&= dosmthing2();
success &&= dosmthing3();
if (success)


3 commentaires

Comment tout peut se comporter comme quelque chose qui n'existe pas? Pas une vraie question.


@Ejp désolé, mais je doute vraiment que quiconque ait des problèmes d'imaginer comment cet hypothétique && = se comporterait s'il existait, à part de l'ambiguïté concernant le court-circuit, mais qui peut très bien être demandé de L'OP (qui n'a probablement pas pensé à court-circuiter du tout). Pas un vrai vote rapproché.


@Christianrau je sais sur Sceval, mais tbh je n'en pensais pas quand demander ce q


4 Réponses :


4
votes

non; Ce n'est pas court-circuit.

bool x = false;
x &= (cout << "You shouldn't see me!");


3 commentaires

Même s'il s'agissait de court-circuit, le fonctionnement binaire est toujours différent du logique.


@ H2CO3 Si les deux arguments ont le type bool , la seule différence entre & et && est le court-circuit. (C'est pourquoi, par exemple, nous n'avons pas besoin d'un opérateur ^^ . Depuis exclusif ou ne peut jamais court-circuiter, il n'y a pas besoin d'un opérateur de court-circuit.)


@Jameskanze true. Sauf que, parfois, ce serait un raccourci pratique pour être converti sur contextuellement-to-bool-et non-égal.



6
votes

Non, et est un bitwise et, && est booléen et. Si dossming * retourne quelque chose d'autre que 1 ou 0, les résultats seront différents.


12 commentaires

Ne fait aucune différence pour les booléens. Mais il est vrai que si les fonctions possibles ne retournent pas Bool, cela pourrait faire la différence.


@Sebastianredl pourquoi pas? C'est sûrement. Les booléens ne sont pas des valeurs 1 bits.


Conceptuellement, ils sont. En ce qui concerne l'arithmétique binaire, ils sont.


@Sebastianredl En réalité, ils ne peuvent pas être, C ++ n'a pas de type "vrai" de type booléen 1 bit. La mise en œuvre serait de sorte que ce fait matière.


Non, ça ne le fait pas. Étant donné que chaque true sera converti en 1 et tous les false sur 0 , le résultat du bitwise et est le même comme si vous faites une logique et sur les booléens originaux. Les résultats ne diffèrent que si l'une des intrants n'est pas, en fait, un booléen.


C'est-à-dire que le Bool occupe plus d'un peu en mémoire, mais la langue ne concerne que même avec 1 bit. Les autres ne font que rembourrer et ignoré.


@Sebastianredl puisque nous ne savons pas quel type DosMThing retourne, & && ne sont pas les mêmes. Si Divertissement1 renvoie une valeur entière 2, && va évaluer comme vrai, alors que et fera favoriser le booléen à 1 et résultera de faux.


Comme je l'ai dit dans mon premier commentaire, si les fonctions possibles ne retournent pas Bool, il y a une différence.


@Nosenseetal Dans ce cas, il se résume à & = pas court-circuit.


@zennehoy TNX, c'est ce que je voulais savoir, AKA est un compilateur autorisé à représenter BOOL par "Char qui a au moins un bit défini sur 1", puis et = sur deux true-s pourrait retourner 0 (faux).


@Nosenseetal "est le compilateur autorisé à représenter Bool par" Char qui a au moins un bit défini sur 1 "" - le compilateur est autorisé à représenter bool s de quelque manière que ce soit voit l'ajustement (il pourrait même représenter true par une valeur 64 bits avec tous les 0 et false par tous les 1s), mais c'est complètement non pertinent. Ce qui compte comment bool s est converti en int s (et vice-versa) et qui est garanti par la norme, car les opérateurs bitwises ne fonctionnent pas sur bool s du tout, ils sont convertis en int à l'avance ...


@Nosenseetal ... de la même manière double d = 1,0 et 0,0; est garanti de 0,0, quelle que soit la représentation des points flottants, car & ne Travailler sur des doubles du tout.



9
votes

Cela dépend de la manière dont vous attendez && = fonctionner. Si vous voulez x && = y (); équivalent à x = x && y (); , alors non, car dans cette expression y () n'est pas appelé si x démarre comme false, mais dans x & = y (); ce sera.

Si vous ne vous attendez pas à ce que ce soit court-circuit et que toutes vos expressions ont vraiment de type bool (pas quelque chose de convertible vers bool , comme des pointeurs, des entiers, ou objets définis par l'utilisateur), ça marche. C'est beaucoup de restrictions cependant.


6 commentaires

L'exigence de court-circuit est la critique. Si dosomething1 () retourne false, dosomething2 et dossomique3 ne doit pas être appelé (j'imagine).


@Jameskanze parfois je dois appeler toutes les fonctions parfois je ne


@Nosenseetal Si vous devez appeler toutes les fonctions, vous ne pouvez pas utiliser && , peu importe. L'ensemble du point de && est-il court-circuit court, s'arrêtant au premier argument qui retourne faux.


@Jameskanze Dans ce cas, j'ai vérifié si rv == faux jeu SUCCESS = FALSE, mais oui, vous avez raison dans ce formulaire, il n'est pas utilisable


Donc, juste pour indiquer clairement qu'il est impossible de dire que si Bool A est vrai et que Bool B est vrai qu'après A & = B A est faux?


@Nosenseetal Comment cela serait-il possible? OK, la réponse aurait pu être améliorée par certaines références aux règles de promotion intégrées et aux conversions Int-Bool.



4
votes

Ils sont complètement différents. Dans ce cas, le court Circuit de && semble important: si doSmthing1 () retourne false, dosmthing2 et doSmthing3 ne serait pas appelé si vous Utilisez && . Ils seront appelés si vous utilisez & .

Dans ce cas particulier, pourquoi pas seulement écrire: xxx

Ceci semble tout aussi clair ( au moins formaté comme ça), et Évite tout besoin de && = .


0 commentaires