J'ai vu du code qui ressemble à ceci: existe une différence de performance entre les performances ci-dessus et En général, quel serait le cas préféré de gérer cela? Peut-être que sans l'autre dans mon deuxième exemple? Edit: il semble que beaucoup de gens étaient induisaient par le fait que je reviens vrai ou faux et suggère de revenir! (A || B || c). Ce n'était pas ce que je voulais demander. Imaginez si au lieu de retourner true ou false, je veux retourner "oui" ou "non", 23423 ou 3.
5 Réponses :
Tout est tout issu de la manière dont le compilateur compile le code. Pour toutes les raisons pratiques, elles sont identiques. (Tant que vous vous assurez d'utiliser des courtes courtes ou «||»)
@Ray: Dis-moi comment pas Utiliser un raccourci ou "||" en C ++?
Je suis un peu rouillé sur C ++ maintenant, mais je crois que si A et B et C sont des chiffres, vous pouvez utiliser le bitwise ou parce que c ++ considère 0 pour être faux, et non à zéro pour être vrai. S'il vous plaît vous sentez la bienvenue pour me corriger cependant.
@Ray: Vous êtes déroutant un peu confus avec logique, qui en C ++ sont des opérateurs distincts (nommément: | vs. code> || ).
Si je me souviens bien, C ++ ne se distingue pas le bool et les numériques qui ...
@AY: Vous êtes correct ... cela fonctionnerait dans la plupart des cas, même s'il pourrait être moins efficace (pour avoir à évaluer tous les A, B et C) ou plus (pour éviter les déclarations de branchement). C'est définitivement une mauvaise idée, car elle suggère une signification subtile aux valeurs de bits qui n'existent pas. Et cela ne fonctionne pas si bien pour et, par ex. 1 & 2 est false tandis que 1 && 2 est vrai .
@sehe: Eh bien, C ++ n'est pas tout court-circuit que vous connaissez - voir ma réponse: Stackoverflow.com/questions/1758608/...
@Tony: Cela pourrait être pertinent en fonction du type de A , b , c (et la présence d'opérateurs surchargés dans les champs d'espace de noms accessible )
@sehe: Le moyen de ne pas utiliser de court-circuit opérateur || est de surcharger. Le type d'expressions A , b , c n'est pas indiqué ici, et s'il n'est pas un type intégré, alors opérateur || fait pas court-circuit - ils seront tous évalués.
@Steve Jessop: Ma déclaration ( [...] et la présence d'opérateurs surchargés dans les champs d'espace de noms accessibles ) est plus précis. Le problème est que même des types non intégrés raccourci avec une conversion implicite appropriée vers BOOL (par exemple); Maintenant, ADL / Koenig Recherche est suffisamment délicate pour faire que moins que des surcharges évidentes des opérateurs logiques existent.
Le seul avantage de l'une ou l'autre serait la lisibilité, il serait raisonnable qu'un compilateur d'optimisation générerait du code presque identique pour les deux cas.
Si les 3 tests sont courts, alors Si toutefois, ils sont des appels de fonction longue, votre premier exemple serait plus facile à lire. retour! (A || b || c); est parfaitement raisonnable
En bref: il n'y a pas de différences significatives dans le code et vous pouvez plus raccourcir votre code en l'écrivant comme Si vos conditions sont vraiment simples, par exemple Parfois, vous verrez des conditions qui sont simplement massives et que, dans ce cas, il est préférable de les diviser en morceaux de plus petits morceaux (via plusieurs déclarations si ou en formaçant votre code). De toute façon, il ne s'agit que d'une lisibilité Le compilateur est super-sucré et produira (presque) code identique pour tout ce que vous écrivez dans ces cas. retour! (A || B || c);
if (grata_is_invalid || login_failed) alors vous pouvez les combiner dans une ligne comme vous le suggéré.
&&, || et ? sont opérateurs de court-circuit en C ++, ce qui signifie que le deuxième argument n'est évalué que si le D'abord ne détermine pas la valeur de l'expression.
Cela signifie que vous pouvez simplement écrire, pour votre code d'échantillon:
"&&, || et? sont des opérateurs de court-circuit en C ++" - sauf si elles sont surchargées. S'il y a une chance que le code d'origine s'appuie sur le fait que B n'est pas évalué si A est vrai, alors vous devez vérifier les types impliqués avant de faire ce changement .
Séparer les ifs et utiliser || L'opérateur n'est pas spécifiquement identique! Si l'un des A, B ou C sont des types définis par l'utilisateur et surcharger, soit || Ou opérateur de conversion sur tout type d'entier ou de pointeur, les deux constructions peuvent donner des résultats différents!
pourquoi pas simplement
retourner a || B || C (en supposant que les expressions réellesa ,b etc sont raisonnablement courts ...)Il pourrait vouloir retourner 1 et 2 plutôt que vrai ou faux?
@Dirk: C'est être
retour! (A || b || c) pour les exemples donnés, mais je suis tout à fait d'accord avec l'utilisation deretour expression ."Imagine si au lieu de retourner vrai ou faux" ...
retour! (A || b || c)? "Oui": "non"; (ouretour "oui \ 0no \ 0" + (A || b || c) * 4; ;-p)Wtf!
retour "oui \ 0no \ 0" + (a || b || c) * 4; ?? S'il vous plaît, ne suggérez pas de choses que vous ne voudriez pas que vos collègues écrivent, vous pourriez avoir une personne en pensant que le code obscurcissant est une bonne idée. Vous ne voulez sûrement pas maintenir un produit rempli de ce type de code ...@David: Je suppose que même des blagues étiquetées clairement sont-elles sous la nouvelle catégorie "non constructive"? Après tout, nous ne voulions pas que les gens n'utilisaient donc parce qu'ils en profitaient ;-p
@Tony +1 pour la lisibilité - je savais quand j'ai édité mon commentaire que quelqu'un suggérerait de faire ça :)
@Steve Jessop: Tu ne comprends pas! Donc, on ne peut pas être fait agréable, il est trop addictif car il s'agit de le rendre meilleur!
@David: Hé ... Si vous me faites rire de mon bureau, mes collègues pourraient m'aimer à la ferme amusante ...!