Unterschied zwischen "not" und "false"?

[romber]

Hallo!

Gibt es irgenwelche Unterschied zwischen

Delphi-Quellcode:

if irgendwas = false then

und

Delphi-Quellcode:

if not irgendwas then

Sind die beide Methoden gleich schnell?

[DeddyH]

Ob sie gleich schnell sind, kann ich Dir nicht sagen. Allerdings sollte man nie auf true oder false prüfen, da dies zumindest bei true in die Hose gehen kann.

[omata]

Beides ist gleich.

Nur das...

Zitat:

Zitat von romber (Beitrag 1041240)

Delphi-Quellcode:

if irgendwas = false then

zum ko**en ist! Und nicht wirklich guter Stil.

[Sir Rufo]

Ja

Tut man nicht

Delphi-Quellcode:

if irgendwas = false then

Das ist korrekt

Delphi-Quellcode:

if not irgendwas then

Den erzeugten Code kannst du über den Debugger rausfinden.
Wenn der gleich sein sollte (Compilermagic) dann ist es gleich schnell

Ansonsten einfach mal die Zeit messen

[vlees91]

Zitat:

Zitat von romber (Beitrag 1041240)

Delphi-Quellcode:

if irgendwas = false then

und

Delphi-Quellcode:

if not irgendwas then

der (Delphi 2006) compiler compiliert beides zu

Code:

test bl, bl
jnz xxx

Es ist also EXAKT gleich.

Wenn man allerdings

Delphi-Quellcode:

if (irgendwas = true) then

macht, wird dies

Code:

cmp bl,1
jz xxx

und

Delphi-Quellcode:

if (irgendwas) then

wird

Code:

test bl,bl
jz xxx

Also wie gesagt ist es egal was man bei false macht aber bei true sollte man aufpassen.

[mkinzler]

Das 1. bedeutet ja das Vergleich irgendwas = false true sein muss:

Code:

  irgendwas: false
     false = false -> true
  irgendwas: true
    false = true -> false

Das 2. das die Variable negiert wird

Code:

  irgendwas: false
    false -> true
  irgendwas: true
    true -> false

Das Problem ist das true als <> 0 deklariert ist, also True nicht unbedingt True ist.

[himitsu]

Delphi-Quellcode:

var b: Boolean;
begin
  Memo1.Lines.Add('');
  Memo1.Lines.Add('b := false;');
  b := false;
  if b then Memo1.Lines.Add('if b then');
  if not b then Memo1.Lines.Add('if not b then');
  if b = false then Memo1.Lines.Add('if b = false then');
  if b = true then Memo1.Lines.Add('if b = true then');

  Memo1.Lines.Add('');
  Memo1.Lines.Add('b := true;');
  b := true;
  if b then Memo1.Lines.Add('if b then');
  if not b then Memo1.Lines.Add('if not b then');
  if b = false then Memo1.Lines.Add('if b = false then');
  if b = true then Memo1.Lines.Add('if b = true then');

  Memo1.Lines.Add('');
  Memo1.Lines.Add('b := 3;');
  b := Boolean(3);
  if b then Memo1.Lines.Add('if b then');
  if not b then Memo1.Lines.Add('if not b then');
  if b = false then Memo1.Lines.Add('if b = false then');
  if b = true then Memo1.Lines.Add('if b = true then');
end;

[DeddyH]

Möchte noch jemand etwas zum Thema "nicht auf true prüfen" beitragen? 55.071 Users left :stupid:

[romber]

Vielen Dank für so viele Anregungen!

Zitat:

Zitat von DeddyH (Beitrag 1041242)

...Allerdings sollte man nie auf true oder false prüfen, da dies zumindest bei true in die Hose gehen kann.

Wie meinst Du das?

[DeddyH]

Hast Du den Code von himitsu einmal ausprobiert?

[mkinzler]

Zitat:

Wie meinst Du das?

Alles lesen

Zitat:

Das Problem ist das true als <> 0 deklariert ist, also True nicht unbedingt True ist.

[vlees91]

Zitat:

Zitat von romber (Beitrag 1041259)

Wie meinst Du das?

Direkter Unterschied fuer die Augen (in asm)
http://www.delphipraxis.net/1041247-post5.html

[Sherlock]

:shock:
Also, wer so was macht

Delphi-Quellcode:

b := Boolean(3);

, der nutzt auch undokumentierte API-Funktionen :lol:. Bei mir sind Bool immer wirklich Bool, dann wäre (ich mach sowas nicht) eine Frage nach true auch ohne Konsequenzen.

Sherlock

[himitsu]

@Sherlock: das ist nur die Kurzform ... stell dir mal vor du bekommst den Bolean als Result von einem ASM-Code oder irgendeiner anderen externen Quelle ala C++-Code und Co.

[guinnes]

http://www.delphi-treff.de/tutorials...faengerfehler/

[xZise]

Zitat:

Zitat von Sherlock (Beitrag 1041292)

:shock:
Also, wer so was macht

Delphi-Quellcode:

b := Boolean(3);

, der nutzt auch undokumentierte API-Funktionen :lol:. Bei mir sind Bool immer wirklich Bool, dann wäre (ich mach sowas nicht) eine Frage nach true auch ohne Konsequenzen.

Sherlock

Das ist eine Frage der Definition. Der Wahrheitswert "wahr" ist nicht 0. Das heißt, der Boolean b := 3 ist ein gültiger Wahrheitswert. Abgesehen davon ist der Boolean ja auch 8 bit breit. Ich meine wenn du eine Spezifikation hast in der steht: Wenn auf der Leitung keine Spannung anliegt, dann ist das falsch, ansonsten wahr, und du guckst, ob eine negative Spannung anliegt, aber auch positive Spannungen anliegen können, dann hast du es falsch implementiert.

MfG
Fabian

[romber]

OK, vielen Dank!

[WM_CLOSE]

in den älteren Delphi versionen (ich glaube<6) hängt das von den Definitionen von "true" und "false" ab:
einige API funktionen geben kein Delphi true zurück, sonder eines aus c/c++ das ist dann von mir aus nicht 1 sondern <> 0

[rollstuhlfahrer]

Zitat:

Zitat von WM_CLOSE (Beitrag 1041352)

einige API funktionen geben kein Delphi true zurück, sonder eines aus c/c++ das ist dann von mir aus nicht 1 sondern <> 0

Nicht ganz. Es ist sogar -1 und das ist das ganz große Problem:
true (Delphi) = 1, false (Delphi) = 0
true (C) = -1, false (C) = 0
Das kommt daher, weil man für C den Wert Byte($FF) benutzt, bei dem nun mal -1 rauskommt.

Bernhard

[Sfaizst]

Ich programmier jetz schon relativ lange, aber jetz brennt mir doch ne ziemlich primitive frage auf der zunge.

Wie kann ein Byte, welches 8 Bit hat und im wertebereich von 0..255 liegt bei $FF (ist bei mir 255 sogar mitm wincalc (auch wenn ichs so wusste) ) den Wert -1 annhemen?

[rollstuhlfahrer]

-1 hat aber auch bei calc den Byte-Wert FF.

[mkinzler]

Weil bei signed das oberste Bit das Vorzeichen bestimmt

Wegen 0 - Zahl = negative Zahl

Code:

0           -       1 =       -1
00000000(1) - 1000000 = 11111111

[xZise]

Siehe dazu das Zweierkomplement.

Und das andere: Es ist Definitionssache ;) Wenn du $FF in einen unsigned Byte schreibst, dann hast du 255. Aber in der Regel werden vorzeichenbehaftete Datentypen genommen.

Außerdem ist das doch glaub ich andersherum: true = -1 in Delphi oder nicht?

MfG
Fabian

[rollstuhlfahrer]

Ich habs noch nicht ausprobiert, aber da sollte +1 rauskommen. In Delphi ist der Boolean wohl so definiert:

Delphi-Quellcode:

type Boolean = (false, true);

und damit ist true +1 und false 0.

Bernhard

[mkinzler]

Ja aber der Wert wird in einem Byte gespeichert un deshalb sind andere Werte möglich und wie schon gezeigt wurde leifern bestimmte Funktionen andere Werte.
Kurz gesagt ist alles was nich false ist true ( <> 0)

[himitsu]

-1 in einem signed und mit Überlauf in einem unsigned Register (32 Bit) ist $FFFFFFFF ... tja und wenn man dieses auf ein Byte kürzt, dann kommt eben $FF raus.

Abgesehn davon daß viele WinAPIs eh LongBool (32 Bit) nutzen.

[mkinzler]

Das hat nichts mit dem Überlauf zu tun, sondern wie oben geschrieben das 0 - eien zahl deren inverses Element ergibt bzw. Zahl + Komplement = 0

[uligerhardt]

Um das zu entscheiden, braucht man keinen CPU-View oder ASM-Code.

• Delphi-Quellcode:

  if not List.IsEmpty then

  heißt "Wenn die Liste leer ist, dann...".
• Delphi-Quellcode:

  if List.IsEmpty = false then

  heißt "Wenn es falsch ist, dass die Liste leer ist, dann...".

Ich muss da nicht nachdenken, welche Variante ich nehme. :mrgreen:

[rollstuhlfahrer]

Kleiner Denkfehler:

if not List.IsEmpty bedeutet: Wenn nicht die Liste leer ist -> die Liste ist also nicht leer -> in der Liste ist was drin

if List.IsEmpty = false bedeutet: Wenn es falsch ist, dass die Liste leer ist, wobei .IsEmpty glücklicherweise eine Delpi-eigene Funktion ist, wodurch das hier geht, aber nicht schön ist, weil man über das = false beim lesen stolpern könnte.

Du willst wohl ausdrücken: Wenn die Liste nicht leer ist, dann...; heißt im Englischen: if the list is not empty. Aus den Kursiv gedruckten Wörtern erschließt sich dann, was man in Delphi dann schreiben muss.

Bernhard

[uligerhardt]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1041385)

Kleiner Denkfehler:

if not List.IsEmpty bedeutet: Wenn nicht die Liste leer ist -> die Liste ist also nicht leer -> in der Liste ist was drin

Ähm, ich wollte natürlich schreiben:

Zitat:

Delphi-Quellcode:

if not List.IsEmpty then

heißt "Wenn die Liste nicht leer ist, dann...".

:oops:

[himitsu]

jetzt das

Delphi-Quellcode:

if not List.IsNotFull then

.

Tschuldschung, aber ich konnt nicht anders. :oops:



Nja, es ist eigentlich recht einfach:

> True und False sind Werte/Konstante, welche je "einen" definierten Wert darstellen.

> Boolean und Co. sind Variablen, welche unterschiedliche Werte enthalten können,
aber es ist so festgelegt, daß 0 = "False" und alles Andere = "True" darstellt.


Und jetzt sollte auch klar werden, warum man nicht mit True und False vergleichen soll.

True/Wahr gibt es mehrfach, aber die Konstannte stellt nur einen Bruchteil davon dar und man kann demnach nur einen Bruchteil erfolgreich damit vergleichen.

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1041393)

und jetzt das

Delphi-Quellcode:

if not List.IsNotFull then

.

Tschuldschung, aber ich konnt nicht anders :oops:

Ich habe schon eine boolsche Variable namens Nicht_OK gesehen, die gerne mal mit

Delphi-Quellcode:

if not Nicht_OK

abgefragt wird. :lol:

[xZise]

Moin,
kann es übrigens sein, dass ein Punkt, warum man false und true umgeht noch nicht genannt wurde? Und zwar wird ja in einer if-Bedingung ein Boolean-Wert erwartet:

Delphi-Quellcode:

if true then

Und wenn der Boolean Wert wahr ist, führt er bestimmten Code aus.

Das heißt wiederum, dass ein Test auf false aber besonders auf true doppelt ist:

Delphi-Quellcode:

if x = true then // Ist quasi: Wenn (x = true) = true dann

Nagut bei false trifft das nicht direkt zu, aber dennoch braucht man in der Regel kein Vergleich mit Wahrheitswerten, sondern kann immer mit Operatoren negieren o.ä. um das zu erreichen.

MfG
Fabian

[Micha88]

Zitat:

der (Delphi 2006) compiler compiliert beides zu:

Code:

test bl, bl
jnz xxx

Das interessiert mich jetzt aber.. wie kommt man in D2009 denn an den Assemlber-Code (das ist doch Asembler?) ?

[himitsu]

Strg+Alt+C (das geht in jedem Delphi) oder mal oben im Menü suchen (Ansicht > Debug > CPU).

[Micha88]

Bei mir ist der Button, welcher zum obigen Shortcut gehört, durchgehend deaktiviert.

[himitsu]

Das läßt sich komischwer Weise nur wärend des Debuggens anzeigen/einblenden.

Zeigt aber sowieso nur Was an, wärend ein Programm angehalten ist.

[p80286]

Kleiner Nachtrag zu (-1) $FF.

Wenn man Integer "nur" zum Rechnen nutzt, dann werden $FF oder $FFFF eigentlich nie als neg. Werte erkannt.
Für mich sind negative Werte, wie auch Buchstaben, eine Interpretationssache.


Gruß
K-H

[mkinzler]

Du brauchst aber nur eine externe Funktion erwischen die -1 (signed) zurückgibt, dann wird es signed als 255 interpretiert, was dann zwar True im Sinne von <> 0 aber nicht True im Sinne von 1 ist.

[Bummi]

Bissel OT aber:

wenn man die CONST Deklaration in einer anderen unit "versteckt" kann man jemanden denke ich ordentlich ärgern.....

Delphi-Quellcode:

procedure TForm5.Button1Click(Sender: TObject);
Const
  true=false;
Var
  Test:Boolean;
begin
  Test := true;
  if Test then Showmessage('true') else  Showmessage('false');

end;