array[1..10] auf Wert prüfen?

[DeddyH]

Die Konstante true ist mit 1 belegt, tatsächlich ist aber alles <> 0 true. Windows-API-Funktionen geben z.B. gern einmal eine negierte 0 zurück, welcher Wert das dann ist, hängt von der Bitbreite ab. Auf jeden Fall schlägt der Vergleich mit 1 dann fehl.

[Delphi.Narium]

Ich frag' mich immer, warum sollte ich

Delphi-Quellcode:

if variabel = true then

schreiben. wenn doch

Delphi-Quellcode:

if varibel then

vollkommend ausreichend ist? Wahrer als wahr wird es nicht.

Oder:

Warum sollte ich

Delphi-Quellcode:

if variabel = false then

schreiben, wenn doch

Delphi-Quellcode:

if not variabel then

ausreicht? Falscher als falsch wird es nicht.

Von mir aus kann man auch noch

Delphi-Quellcode:

case variabel of
  false : Irgendwas;
else
  was anderes;
end;

machen.

Aber, wenn man bei

Delphi-Quellcode:

case variabel of
  false : irgendwas;
  true  : Nochwas;
else
  UppsWas;
end;

in den Else-Zweig kommt, dann ist der Fall eingetreten, vor dem hier ausdrücklich gewarnt wird.

Und wer mal mit Datenbanken arbeitet und .AsBoolean benutzt weiß, dass das nicht immer funktioniert, dort gibt es nämlich den dritten von zwei möglichen Fällen, nennt sich Null.

[p80286]

Zitat:

Zitat von Delphi.Narium (Beitrag 1410386)

Und wer mal mit Datenbanken arbeitet und .AsBoolean benutzt weiß, dass das nicht immer funktioniert, dort gibt es nämlich den dritten von zwei möglichen Fällen, nennt sich Null.

:mrgreen: :thumb:

Ich habe den Eindruck, das diese "irgendeinbool=true-Diskussion" immer öfter hochkocht.
Das erinnert mich an "sinnvoll" und "das macht Sinn". Nur weil ein Konstrukt in der einen Sprache vorkommt, ist es in der anderen Sprache nicht sinnvoll.


Gruß
K-H

[Delphi.Narium]

Wenn ich höre: Das macht Sinn oder Was für einen Sinn macht es frag' ich mich immer: Was ist das für ein ominöses Es, das nichts weiter tut, als Sinn herstellen. Und vor allem, wie wird Sinn gemacht? Und wie kann Es immer und jederzeit überall sein, um dieser Tätigkeit nachzugehen, ohne dass mir je jemand erklären konnte, wie eigentlich "Sinnmachen" geht. Hat Es auf das "Sinnmachen" ein Patent und wenn ja, wie viel verdient dieses Es dann mit der Vermarktung davon?

Auch wenn man das Englische wörtlich ins Deutsche übersetzen kann, so ist es nicht zwingend sinnvoll oder sinnbringend oder in Falschdeutsch: Das macht keinen Sinn. Man könnte auch einfach sagen: "Sinnmachen" ist unsinnig, "keinen Sinn machen" ebenso.

Genausowenig wie

Delphi-Quellcode:

if varibabel = true then

.

Frage ja auch nicht ab:

Delphi-Quellcode:

if (variabel = 1) and (1 = 1) then

oder gar

Delphi-Quellcode:

if (variabel = 0) and (1 = 0) then

;-)

[freimatz]

Aus technischer Sicht ist ein Vergleich mit True überflüssig. Für mich macht es allenfalls noch Sinn wenn man etwas damit ausdrücken möchte und so den Code lesbarer machten will.

Wenn True und False eher gleichberechtigt sind würde ich vielleicht ein Vergleich auf True in Betracht ziehen wie z.B.:

Delphi-Quellcode:

if UntersuchungsErgebnis = True then

Wenn True eher eine Richtigkeit oder Vollständigkeit anzeigt lasse ich das auf jeden Fall weg wie z.B. bei

Delphi-Quellcode:

if UntersuchungsAbgeschlossen then

In den meisten Fällen die obigen ersten Fall entsprechen würde ich aber eher einen eigenen Aufzählungstyp definieren wie z.B.

Delphi-Quellcode:

TUntersuchungsErgebnis = (positiv, negativ);

Dann wird gleich auch der Typ immer vom Compiler geprüft.

Obige Unterscheidung kommt bei mir ähnlich häufig bei unit tests vor. So schreibe ich z.B.:

Delphi-Quellcode:

CheckTrue( Assigned(parameter) )

andererseits

Delphi-Quellcode:

CheckEquals(True, Testklasse.UntersuchungsErgebnis);

oder

Delphi-Quellcode:

CheckEquals(False, Testklasse.UntersuchungsErgebnis);

[Dennis07]

Um nochmal auf das Problem zurückzukommen, ich würde es sogar mit einer

Delphi-Quellcode:

for in

-Schleife machen, da man hier ja nur lesezugriff braucht. Wäre noch etwas schneller und einfacher:

Delphi-Quellcode:

function AssertArray(AArray: TArray<Boolean>): Boolean;
begin
  for Result in AArray do
  begin
    if not Result then
    begin
      Exit;
    end;
  end;
end;

Das wäre sicherlich die Eleganteste Lösung.

[himitsu]

Auf was Result wohl steht, wenn das Array leer ist? :roll:

Und per Definition sind Array-Variablen außerhalb der Schleife ungültig/undefiniert, unabhänbgig davon ob das manchmal/oftmals nicht so ist.

[Dennis07]

Zitat:

Zitat von himitsu (Beitrag 1410406)

Auf was Result wohl steht, wenn das Array leer ist? :roll:

Dann ist der Rückgabewert undefiniert. Was Allerdings ja nicht sein kann, da das Array ja bei ihm angeblich immer 10 hat. Aber selbst wenn nicht, was soll denn in so einem Fall korrekterweise widergegeben werden?

Delphi-Quellcode:

True

, weil es kein

Delphi-Quellcode:

False

gibt oder

Delphi-Quellcode:

False

, weil es kein

Delphi-Quellcode:

True

gibt? Wenn du das entschieden hast, kannst du ja dann noch eine Initializierung unten vornehmen. Oder, wohl noch besser, vorher auf

Delphi-Quellcode:

Length(AArray <> 0)

prüfen und ansonsten eine Fehlermeldung ausgeben.

Zitat:

Zitat von himitsu (Beitrag 1410406)

Und per Definition sind Array-Variablen außerhalb der Schleife ungültig/undefiniert, unabhänbgig davon ob das manchmal/oftmals nicht so ist.

Nö, außerhalb der Schleife sind es normale lokale Variablen. Bei

Delphi-Quellcode:

for

kann es allerdings passieren, dass sie nicht initialisiert wurden. Das passiert immer genau dann, wenn sie nicht ein einziges mal durchlaufen wurde. Ansonsten hält sie immer den Wert des letzten Durchlaufs (check after loop).

[himitsu]

Der Witz ist, dass der Compiler die Zählvariable optimieren kann und aus eimen

Delphi-Quellcode:

for i := 1 to 11 do

intern schonmal zu einem

Delphi-Quellcode:

for i := 10 downto 0 do

wird.
Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

[Dennis07]

Zitat:

Zitat von himitsu (Beitrag 1410446)

Der Witz ist, dass der Compiler die Zählvariable optimieren kann und aus eimen

Delphi-Quellcode:

for i := 1 to 11 do

intern schonmal zu einem

Delphi-Quellcode:

for i := 10 downto 0 do

wird.
Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

Was zwar sein kann (ist mir zwar noch nicht unter gekommen, aber das Gerücht habe ich auch schonmal gehört), allerdings ist es für

Delphi-Quellcode:

for in

-Schleifen ja eh völlig egal, in welcher Reihfolge diese ausgeführt werden. Du kannst ja mal meinen Code durchgehen unter der Prämisse, dass eine

Delphi-Quellcode:

for in

-Schleife immer Rückwärts ausgeführt werden würde, und wirst feststellen, dass es am Ergebnis und der Funktionalität der Routine absolut gar nichts ändert.