Verständnisfrage: IF (Bedingung1 ODER Bedingung1)

[Jim Carrey]

Eine kleine Verständnisfrage hätte ich.

Wenn bei folgender If-Konstruktion A = B bereits zutrifft, wird C = D dann noch überprüft oder nicht? Das Frage ich mich schon seit langer Zeit

Delphi-Quellcode:

if (A = B) or (C = D) then

[Der schöne Günther]

http://docwiki.embarcadero.com/RADSt...n_im_Vergleich

https://de.wikipedia.org/wiki/Kurzschlussauswertung

Kurze Antwort: Nein.

Etwas längere Antwort: Nein, es sei denn du hast in den Projekt-Optionen "Vollständige boolsche Auswertung" aktiviert (warum sollte man so etwas tun?)

[Darlo]

Oder wenn Du es testen willst:

Delphi-Quellcode:

procedure TfrmMain.Button3Click(Sender: TObject);
var
  myPanel: TPanel;
begin

if (1=1) or (myPanel.Name = 'test') then
  showmessage('a');

if  (myPanel.Name = 'test') or (1=1) then
  showmessage('b');

end;

[DeddyH]

Müsste das nicht *Puff* machen? Immerhin greifst Du auf die Eigenschaft einer Instanzvariablen ohne Instanz zu.

[Neutral General]

Zitat:

Zitat von DeddyH (Beitrag 1351198)

Müsste das nicht *Puff* machen? Immerhin greifst Du auf die Eigenschaft einer Instanzvariablen ohne Instanz zu.

Ich glaube das ist genau der Test. Bei "a" krachts nicht, weils gar nicht ausgewertet nicht und bei "b" schon.

[DeddyH]

Ach, wenn das so gedacht war, habe ich nichts gesagt :)

[Darlo]

:) Hätte es in der Tat mehr ausführen können.

[Neutral General]

Wollte auch erst schreiben dass ich nicht verstehe wie das ein Test sein soll.
Und dann kam grad vorher noch DeddyHs Post und erst dann kam die Erleuchtung :mrgreen:

[himitsu]

Wobei myPanel nicht initialisiert ist ... Wenn da "zufällig" ein Wert drin steht, der einen Zeiger auf ein TComponent darstellt, dann knallt es nicht. :stupid:

PS:

Delphi-Quellcode:

{$BOOLEVAL ON}

-> http://docwiki.embarcadero.com/RADSt...ler-Direktive)
Hmmmmm, was ist mit XOR?

Zitat:

Zitat von dokwiki

für die Booleschen Operatoren und und oder um

Und ja, bei Delphi stimmt es, aber z.B. bei PostgrSQL muß man aufpassen.

Die Optimierung kann da diese Prüfungen austauschen/umdrehen und dann knallt's.

UND, in C-Sprachen ist die Auswertungsreihenfolge der Operatoren andersrum, als im Delphi. ( == vor AND statt AND vor =)

[Darlo]

Zitat:

Zitat von himitsu (Beitrag 1351207)

Wobei myPanel nicht initialisiert ist ... Wenn da "zufällig" ein Wert drin steht, der einen Zeiger auf ein TComponent darstellt, dann knallt es nicht. :stupid:

Dann hat man den weiteren Programmablauf aber auch verdient ;-)

[TBx]

Zitat:

Zitat von DeddyH (Beitrag 1351198)

Müsste das nicht *Puff* machen?

[OT]Meinst Du, Luckie muss immer bei jedem Fehler ran? :mrgreen:[/OT]

[bra]

Zitat:

Zitat von himitsu (Beitrag 1351207)

UND, in C-Sprachen ist die Auswertungsreihenfolge der Operatoren andersrum, als im Delphi. ( == vor AND statt AND vor =)

Was ich besser finde, da man sich so viele Klammern spart, die man bei Delphi leider immer braucht... und es ist zu bestimmt 99% der Fall, dass man bei einem a = b and c = d nicht zuerst das and ausgewertet haben will...

[himitsu]

Zitat:

Zitat von bra (Beitrag 1351212)

und es ist zu bestimmt 99% der Fall, dass man bei einem a = b and c = d nicht zuerst das and ausgewertet haben will...

Dann hast du noch nicht viel mit Bitmasken gearbeitet :angle2:

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1351233)

Zitat:

Zitat von bra (Beitrag 1351212)

und es ist zu bestimmt 99% der Fall, dass man bei einem a = b and c = d nicht zuerst das and ausgewertet haben will...

Dann hast du noch nicht viel mit Bitmasken gearbeitet :angle2:

Die meisten von uns halten ihre eigene beschränkte Sichtweise für allgemeingültig.
Der Unterschied liegt in der Heftigkeit des Schubs, den man braucht, um zu bemerken wie nah der Tellerrand ist.

Gruß
K-H

[bra]

Zitat:

Zitat von himitsu (Beitrag 1351233)

Zitat:

Zitat von bra (Beitrag 1351212)

und es ist zu bestimmt 99% der Fall, dass man bei einem a = b and c = d nicht zuerst das and ausgewertet haben will...

Dann hast du noch nicht viel mit Bitmasken gearbeitet :angle2:

Nein, hab ich nicht und ich wage zu behaupten, dass der Großteil der Programmierer das auch nicht ständig tut. Soweit kann ich schon noch über den Tellerrand schauen.

[himitsu]

Och, man gewöhnt sich an fast alles.
Dafür muß man in C noch 'ne Klammer um Alles drum machen, was dann auch viele wieder in Delphi nachmachen.

Delphi-Quellcode:

if (...) {
}

if (...) then begin
end;

if ... then begin
end;

Und so mancher macht so viele (unnötige) Klammern, dass man erstmal schauen muß was wo anfängt und aufhört.

[Jim Carrey]

Zitat:

Zitat von himitsu (Beitrag 1351245)

Und so mancher macht so viele (unnötige) Klammern, dass man erstmal schauen muß was wo anfängt und aufhört.

VisualStudio hat da ein schönes Feature, welches die Klammern einfärbt.
Das hat Delphi, wie immer, natürlich nicht, obwohl es hunderte Euros kostet.

[bra]

Zitat:

Zitat von himitsu (Beitrag 1351245)

Och, man gewöhnt sich an fast alles.
Dafür muß man in C noch 'ne Klammer um Alles drum machen, was dann auch viele wieder in Delphi nachmachen.

Delphi-Quellcode:

if (...) {
}

if (...) then begin
end;

if ... then begin
end;

Und so mancher macht so viele (unnötige) Klammern, dass man erstmal schauen muß was wo anfängt und aufhört.

Naja, ich glaube da scheiden sich die Geister. Ich persönlich finde die Klammern {..} bei C usw. einfacher zu lesen als bei Delphi das begin...end, einfach weil es sich optisch viel besser vom restlichen Code abhebt. Rein vom tippen ist begin..end allerdings wiederum einfacher, weil vor allem auf deutschen Tastaturen das Eingeben von {} jedesmal ein Krampf ist.

Und ich gehöre auch zu denen, die bei if .. then lieber gleich ein begin..end anhängen, weil es sich so leichter erweitern lässt. Macht man überall nur ein
if .. then
machwas
else
machwasanderes;
und will noch eine zweite Anweisung innerhalb des if-Blockes anhängen, produziert man entweder einen Logikfehler, wenn das begin..end fehlt oder muss es auch wieder ergänzen.

[Aviator]

Zitat:

Zitat von Jim Carrey (Beitrag 1351246)

Zitat:

Zitat von himitsu (Beitrag 1351245)

Und so mancher macht so viele (unnötige) Klammern, dass man erstmal schauen muß was wo anfängt und aufhört.

VisualStudio hat da ein schönes Feature, welches die Klammern einfärbt.
Das hat Delphi, wie immer, natürlich nicht, obwohl es hunderte Euros kostet.

Installier dir CnPack. Das rüstet das nach. Funktioniert top und hilft extrem.

[Jim Carrey]

Das ist zwar jetzt total OffTopic aber...
kann ich mein Delphi irgendwie reparieren und FireMonkey nachinstallieren? Denn ohne den Affen funktioniert CnPck nicht.

[himitsu]

Zitat:

Zitat von Jim Carrey (Beitrag 1351250)

Das ist zwar jetzt total OffTopic aber...
kann ich mein Delphi irgendwie reparieren und FireMonkey nachinstallieren? Denn ohne den Affen funktioniert CnPck nicht.

Wir haben cnPack leider installiert und dafür waren keine Tiere nötig. (gibt's in XE eh nicht)

[himitsu]

Ich hab grade im XE einen eigenartigen Fehler gefunden.
Da sucht man sich echt dumm und dusselig danach, wenn das ab und an in einen OnPopup auftritt,
denn die erste Codezeile läuft erfolgreich durch und die Zweite knallt, mit einer wunderschönen Zugriffsverletzung.

Obj.Count=0 und daher löst Obj.Prop[0] eine Exception aus.

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) and (Obj.Prop[0].GetVariant('ein String') = 'xxx');
xxx.Enabled := (Obj.Count = 1) and not Obj.Prop[0].GetVariant('ein Boolean');

Hatte erst geschaut, ob {$BoolEval} ausversehn aktiv ist, aber nee.
Es knallt einfach, wenn ein implizier Cast auftritt, weil trots {$BoolEval off} der Getter ausgeführt wird
und bei einem explizitem VarAsBool oder Boolean-Cast drumrum, passiert das nicht.

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) and not Obj.Prop[0].GetVariant('ein Boolean');  // knallt
xxx.Enabled := (Obj.Count = 1) and not Boolean(Obj.Prop[0].GetVariant('ein Boolean'));  // knallt nicht
xxx.Enabled := (Obj.Count = 1) and not VarAsBool(Obj.Prop[0].GetVariant('ein Boolean'));  // knallt och ni

Nach Analyse des Codes, seh ich, dass der Compiler nicht den zweiten Paramter in einen Boolean castet und dann einfach nur ein AND macht,
sondern es wird der erste Parameter in einen Variant gecastet und dann das Ganze in

Delphi-Quellcode:

VarAnd(variant, variant): boolean

reingequetscht.

Tolle Leisung, vom Compiler. :thumbsup:

xxx.Enabled := (Obj.Count = 1) and not VarToBool(Obj.Prop[0].GetVariant('ein Boolean')); // das IMHO Logische
xxx.Enabled := VarAnd(VarFromBool(Obj.Count = 1), VarNot(Obj.Prop[0].GetVariant('ein Boolean'))); // die Idee des Compiler

Code:

// VarAsBool
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d894  // GetCount
dec eax
jnz $0ea7bc20
xor edx,edx
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d89c  // GetProp
lea ecx,[ebp-$38]
mov edx,$0ea7c150
call $0ea6d98c  // GetVariant
lea eax,[ebp-$38]
call $0ea53264  // VarAsBool
test al,al
jz $0ea7bc24
xor edx,edx
jmp $0ea7bc26
mov dl,$01
mov eax,[ebp-$04]
mov eax,[eax+$000004e4]
call $0ea53024  // SetEnabled

// Boolean
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d894  // GetCount
dec eax
jnz $0ea7bc89
xor edx,edx
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d89c  // GetProp
lea ecx,[ebp-$48]
mov edx,$0ea7c150
call $0ea6d98c  // GetVariant
lea eax,[ebp-$48]
call $0ea51668  // VarToBool
test al,al
jz $0ea7bc8d
xor edx,edx
jmp $0ea7bc8f
mov dl,$01
mov eax,[ebp-$04]
mov eax,[eax+$000004e4]
call $0ea53024  // SetEnabled

// implizit
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d894  // GetCount
dec eax
setz dl
lea eax,[ebp-$58]
call $0ea51680  // VarFromBool
lea eax,[ebp-$58]
push eax
xor edx,edx
mov eax,[ebp-$04]
mov eax,[eax+$00000430]
call $0ea6d89c  // GetProp <- hier knallt's dann
lea ecx,[ebp-$68]
mov edx,$0ea7c150
call $0ea6d98c  // GetVariant
lea eax,[ebp-$68]
call $0ea516a8  // VarNot
lea edx,[ebp-$68]
pop eax
call $0ea516f0  // VarAnd
lea eax,[ebp-$58]
call $0ea51668  // VarToBool
mov edx,eax
mov eax,[ebp-$04]
mov eax,[eax+$000004e4]
call $0ea53024  // SetEnabled

[Jim Carrey]

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) and not VarToBool(Obj.Prop[0].GetVariant('ein Boolean')); // das IMHO Logische
//

Ich kenne es nur so

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) and (not VarToBool(Obj.Prop[0].GetVariant('ein Boolean')));
//

Aber hier sieht man mal wie schön der Compiler alles umänert.

Delphi-Quellcode:

xxx.Enabled := VarAnd(VarFromBool(Obj.Count = 1), VarNot(Obj.Prop[0].GetVariant('ein Boolean'))); // die Idee des Compiler
//

[himitsu]

Zitat:

Ich kenne es nur so

In Delphi und eigentlich allen anderen Sprachen haben unäre Operatoren immer vor allem anderen Vorrang und werden von rechts nach links aufgelöst.

Also, die Vorzeichen (+/-) kommen immer zuerst, dann sogleich das NOT und erst danach wird der ganze Rest ausgewertet.
(andersrum kann man +/- und NOT eh nicht schreiben, außer man klammert, also ist quasi Beides gleichrangig und kommt "immer zuerst dran")


Ich kenn aber zuviele, die benutzen NOT wie eine Funktion und schreiben das dann auch so. :wall::freak:

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) And Not(VarToBool(Obj.Prop[0].GetVariant('ein Boolean')));

geklammert wird das dann auch oftmals

Delphi-Quellcode:

xxx.Enabled := (Obj.Count = 1) And (Not(VarToBool(Obj.Prop[0].GetVariant('ein Boolean'))));

Leerzeichen gibt es nicht und um alles kommt sowieso nochmal 'ne Klammer drum.

Delphi-Quellcode:

xxx.Enabled:=((Obj.Count=1)And(Not(VarToBool(Obj.Prop[0].GetVariant('ein Boolean')))));

Aber hier muß man eh zuviele Klammern machen, denn sonst müsste man ja ein Leerzeichen einfügen, damit es nicht

Delphi-Quellcode:

xxx.Enabled:=(Obj.Count=1)AndNotVarToBool(Obj.Prop[0].GetVariant('ein Boolean'));

heißt :lol:
Und wenn man schon konsequent alles klammert, dann doch bitte richtig. :angle2:

Delphi-Quellcode:

xxx.Enabled:=(((Obj.Count)=(1))And(Not(VarToBool(Obj.Prop[0].GetVariant('ein Boolean')))));