seiteneffekte in && und ||
-
darf der compiler hier durch kurzschlussverfahren code überspringen, also nur einmal foo ausführen?
bool foo() { std::cout << "X"; return rand()%2 == 0; } int main() { if ( foo() || foo() ) std::cout << "Yey!" << std::endl; }
-
Er darf nicht, er muss (es überspringen lassen - der Compiler überspringt foo nicht), falls foo() false liefert. Für das würde ich rand noch initialisieren mit srand(time(0)).
-
Ja.*
Du solltest jedoch srand aufrufen (bswp. <ctime> inkludieren und srand(time(0)) aufrufen), ansonsten liefert rand() natürlich immer das Gleiche.
Bei dem logischen Oder ist dann die Bedingung erfüllt, wenn die erste Bedingung ungleich 0 ist, bei dem logischen Und kann die Bedingung nicht erfüllt sein, wenn die erste Bedingung gleich 0 ist.
Daher kann Folgendes geschrieben werdenclass X { public: ... bool Ready() const; ... }; ... void f(const X* x) { if(x && x->Ready()) // x->Ready() wird nicht abgefragt, wenn x==0 { .. } }* Zur Laufzeit wird es ausgewertet
-
oki doki, danke
-
Wenn du möchtest, dass beide garantiert ausgeführt werden,
dann verwende & statt && bzw. | statt ||
-
& | schrieb:
Wenn du möchtest, dass beide garantiert ausgeführt werden,
dann verwende & statt && bzw. | statt ||Es wird zwar beides ausgewertet, aber das Ergebnis ist nicht das, was du haben möchtest:
#include <iostream> using namespace std; int main() { if(1 && 2) cout << "Das war zu erwarten." << endl; if(1 & 2) cout << "Huch? Das hier wird ja gar nicht ausgegeben." << endl; }
-
Michael E. schrieb:
Es wird zwar beides ausgewertet, aber das Ergebnis ist nicht das, was du haben möchtest:
Doch, bei
bools schon. Und wie häufig verwendet man&&, wenn keine boolschen Ausdrücke im Spiel sind?
-
Ich finde & und | äußerst gefährlichen Stil, da das ein Missbrauch ist, Leuten die den Code lesen / maintainen müssen das Leben erschwert und sehr leicht für einen Tippfehler gehalten werden kann.
Wenn man will, dass beides ausgeführt wird, sollte man die Methoden aus der if Anweisung rausholen und vorziehen!
mfg, René~
-
Nexus schrieb:
Und wie häufig verwendet man
&&, wenn keine boolschen Ausdrücke im Spiel sind?Häufig genug, um irgendwann mal Probleme zu bekommen, und zu selten, um im Vorhinein dran zu denken, dass es nicht funktioniert?
-
Michael E. schrieb:
Nexus schrieb:
Und wie häufig verwendet man
&&, wenn keine boolschen Ausdrücke im Spiel sind?Häufig genug, um irgendwann mal Probleme zu bekommen
Ich weiss nicht, wie du das handhabst, aber ich ziehe es normalerweise vor, direkt einen
boolzu haben (oder einen Zeiger). Typkonvertierungen mache ich lieber explizit. Ich finde auch sowas schrecklich:int x = 7; if (x)Michael E. schrieb:
und zu selten, um im Vorhinein dran zu denken, dass es nicht funktioniert?
Habe ich nicht gedacht. Aber nur weil es funktioniert, muss man es noch lange nicht benutzen.
Übrigens habe ich bisher äusserst selten den Fall gehabt, in dem beide Ausdrücke ausgewertet werden müssen. Und sowas wie
&oder|habe ich in dem Kontext auch noch nie benutzt. Aber ich halte die Aussage, man soll die Operatoren für boolsche Ausdrücke nicht benutzen, weil sie mit Nicht-bools unerwartete Ergebnisse liefern, nicht gerade für das Totschlagargument.
Am sichersten ist wohl sowas:
bool And(bool lhs, bool rhs); bool Or(bool lhs, bool rhs);
-
Sind and und or nicht sogar Keywords?
-
Nexus schrieb:
Am sichersten ist wohl sowas:
bool And(bool lhs, bool rhs); bool Or(bool lhs, bool rhs);Das is auch wieder viel zu umständlich.. Warum nicht einfach vorziehen?
bool isAlpha = alpha(); bool isBeta = beta(); if(isAlpha || isBeta) { }mfg, René~
-
kkkk schrieb:
Sind and und or nicht sogar Keywords?
Doch (genau gesagt sind es alternative Darstellungen für Operatoren), aber klein geschrieben. Und die benutzt so ziemlich rein gar niemand...
NewSoftzzz schrieb:
Das is auch wieder viel zu umständlich.. Warum nicht einfach vorziehen?
Ja, würde ich wahrscheinlich sogar auch machen, vor allem wenn man den Fall selten hat. Aber wenn er häufig vorkommt, können fertige Funktionen vielleicht praktisch für temporäre Ausdrücke sein.
Was aber auch cool wäre, ist eine Art Future, sodass
isAlphazwar vor der If-Abfrage deklariert wird, aber im If nur ausgewertet wird, falls nötig. In C++98 könnte man das überstd::tr1::functionrealisieren.