if (dies && das) frage;

Entyl_Sa

Ich denke Mis2com bezog sich auf die zweite Frage.

Sovok

naja das is ne frage der lesbarkeit... besonders im team

Mis2com

Ja, meine Antwort war auf die zweite Frage.

Der Compiler wird es nicht wegoptimieren; wenn man innerhalb eines if-Ausdrucks zwei Funktionen, die performancetechnisch wohl einiges ausmachen, in Relation setzt, kann so etwas durchaus auch etwas ausmachen, nur geschieht so etwas meiner Meinung nach selten.
Der Compiler kann es insofern nicht optimieren, als dass er die Performance der Funktionen nicht kennen kann, weil diese erst zur Laufzeit bestimmt werden kann.

MfG MAV

absolute_beginner

Aber nicht die Klammerung vergessen!
Denn

a == b && c == d

wird als

a == (b && c) == d

interpretiert, da && die größere Priorität (?) hat.

Sicherer ist in diesem Fall hier das Weglassen von true (wie bereits gesagt) oder eine explizite Klammerung.

edit: Noch viiieeel sicherer ist das Denken vor dem Posten.

Shade Of Mine

absolute_beginner schrieb:

Aber nicht die Klammerung vergessen!
Denn
a == b && c == d
wird als
a == (b && c) == d
interpretiert, da && die größere Priorität (?) hat.

das wage ich zu bezweifeln

Mis2com

http://www.cs.niu.edu/~abyrnes/csci241/precedence.htm

absolute_beginner

*argh*

Hm... erst denken, dann posten.
Tatsächlich ist es natürlich genau anders... == ist stärker als &&.

Naja, ist ja noch mitten in der Nacht...

prolog

Entyl_Sa schrieb:

Wenn das_ok() schon false ist, dann wird bei einer && Verknüpfung die nächste Bedinung garnicht erst ausgewertet. Die Abfrage == true kannst du dir übrigens sparen.
if(das_ok() && dies_ok()){   }
reicht.

Und wieder was gelernt. Wusste garnicht dass C++ lazy evaluation benutzt.

Mis2com

Hm, das ist einfach logisch, dass das so geht.
Sowas wie:

if(a() == true)

ist genau so überflüssig, wie:

if((var == 100) == true)

if erwartet einen bool (alles andere wird implizit gecastet, wenn es geht) und wenn da true steht, dann muss mann nicht true==true überprüfen...

geloescht

hmmm... moment mal! was passiert dann eigentlich, wenn ich folgenden code habe:

bool foo()
{
  cout << "Ich bin bereit!";
  return true;
}

bool bar()
{
  cout << "Hallo, Welt!" << endl;
  return false;
}
int main()
{
  if(bar() && foo())
  {
     //tu irgendwas
  }
}

krieg ich dann aufgrund der lazy evaluation das "Ich bin bereit!" garnicht zu sehen? bar() gibt ja sowieso false zurück, also bräuchte doch er theoretisch foo() garnichtmehr ausführen.
Oder hab ich das falsch verstanden?
geloescht

P.S.: Ich weiß, das beispiel ist ziemlich schlechter stil

0rp

es ist nicht spezifiziert, ob (lazy oder nicht) und in welcher reihenfolge die operanden ausgewertet werden

Shade Of Mine

0rp schrieb:

es ist nicht spezifiziert, ob (lazy oder nicht) und in welcher reihenfolge die operanden ausgewertet werden

das wage ich zu bezweifeln.

0rp

Shade Of Mine schrieb:

0rp schrieb:

es ist nicht spezifiziert, ob (lazy oder nicht) und in welcher reihenfolge die operanden ausgewertet werden

das wage ich zu bezweifeln.

4 Except where noted, the order of evaluation of operands of individual
operators and subexpressions of individual expressions, and the order
in which side effects take place, is unspecified. Between the previ-
ous and next sequence point a scalar object shall have its stored
value modified at most once by the evaluation of an expression. Fur-
thermore, the prior value shall be accessed only to determine the
value to be stored. The requirements of this paragraph shall be met
for each allowable ordering of the subexpressions of a full expres-
sion; otherwise the behavior is undefined. [Example:
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // `i' becomes 9

i = ++i + 1; // the behavior is undefined
i = i + 1; // the value of 'i' is incremented
--end example]

http://www.csci.csusb.edu/dick/c++std/cd2/expr.html

Hallo,

4 Except where noted,[...]

und genau hier gibt es eben eine Ausnahme bei den logischen Operatoren, einer der Grundsätze ("short circuit") in C/C++ ist von diesem Punkt nicht betroffen, denn (nur, um das jetzt auch mal mit einem Zitat aus dem Standard zu "beweisen"):

The && operator groups left-to-right.
The operands are both implicitly converted to type bool (clause 4).
The result is true if both operands are true and false otherwise. Unlike &, && guarantees left-to-right
evaluation: the second operand is not evaluated if the first operand is false.

MfG

short cut evaluation

0rp

Unlike &, && guarantees left-to-right evaluation

nagut, hast gewonnen

Sovok

wenn ihr euch schon mit dem standard auseinandersetzt mal ne ähnliche frage

int result=0;

if(success!=(result=func()))
return error;

ich benutzt sowas recht gern um in einer zeile nen wert zu speichern
und auf fehler zu prüfen
hab aber von nem kollegen gehört dass hier nich immer success!=result geprüft
wird

was meint ihr (der zweifler war n vb programmierer )

Wenn func() nicht grad ne Exception wirft, müsste der Vergleich IMO schon durchgeführt werden.

SirLant

Und ihr denkt auch an folgendes:

bool operator&& (const INTEGER &lhs, const INTEGER &rhs)  {
            return (lhs.var && rhs.var);
}

class INTEGER {
    public:
        INTEGER (int i = 0) : var(i) {}
        friend bool operator&& (const INTEGER &lhs, const INTEGER &rhs);
    private:
        int var;
};

INTEGER CloseDB (DBHANDLE *hDB) {
    CloseDBConnection (hDB);
    return INTEGER (1); // Erfolgreich beendet
}

INTEGER GetStatus () {
    // Prüfen ob noch etwas getan werden muss 
    return INTEGER (0); // Es gibt noch etwas zu tun
}

void DoUpdate (DBHANDLE &hDB); // Aktualisiert Datensätze
DBHANDLE * OpenDB (); // Stellt eine DB Verbindung her

int main () {

    DBHANDLE *hDB = OpenDB ();

    DoUpdate (hDB);

    if (GetStatus () && CloseDB (hDB));

    return 0;
}

Edit:
Typo

IMO gibt es keinen Grund, operator&& zu überladen. Davon abgesehen, ist das in dem Fall wohl besser, den operator '==' zu nennen!

if (dies &amp;&amp; das) frage;

if (dies && das) frage;