if (dies && das) frage;

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!

Shade Of Mine

SirLant schrieb:

Und ihr denkt auch an folgendes:

Nein. Warum auch? Darum kümmert sich die Sittenpolizei
Ne, mal im ernst: man überlädt den op&& einfach nicht. Schongarnicht so unlogisch.

da tut es ein
if(foo() == bar())
doch auch, und ist viel logischer.

SirLant

Es geht hier nicht um den Sinn, sondern um das Verhalten der überladenen Funktion,
und wofür den Operator == verwenden?
Der Benutzer der DB-API, geht hier ja irrtümlicherweise von einer anderen Funktionsweise
des operators&& aus.
Ich wollte nur darauf hinweisen.

Edit:
Shade, dass man den operator&& und operator|| aus diesem Grund nicht überladen soll,
ist dir und mir bekannt, aber dem Entwickler der DB-API hat es trotzdem gemacht.
Der Benutzer verwendet den operator&& ganz normal wie bei den built-ins auch, da
er ja nicht weiß, dass dieser sich anderst verhält.
Und darauf wollt ich hinweisen.

Shade Of Mine

SirLant schrieb:

Es geht hier nicht um den Sinn, sondern um das Verhalten der überladenen Funktion,

Man macht sowas aber nicht.

und wofür den Operator == verwenden?

op&& wurde wie op== implementiert, nur falsch. Sprich der Compiler müsste nen Fehler liefern - op&& muss non member sein.

Der Benutzer der DB-API, geht hier ja irrtümlicherweise von einer anderen Funktionsweise
des operators&& aus.

Exakt. Deswegen ist dieser op&& Schrott.
Ich schreib ja auch nicht ne Funktion addiere die 2 Werte mal PI rechnet, das ergebnis halbiert und dann ne Rakte auf den Mond schiesst.

Ich wollte nur darauf hinweisen.

ist aber n ziemlich doofes beispiel.

SirLant

Stimmt, das ist nen Fehler, liegt an der Müdigkeit
Das Beispiel ist doof, weil man sowas normal nicht macht, aber man soll auch kein
iostream.h verwenden und viele tun es trotzdem

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

if (dies && das) frage;