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 if variabel = true then schreiben. wenn doch if varibel then vollkommend ausreichend ist? Wahrer als wahr wird es nicht.

Oder:

Warum sollte ich if variabel = false then schreiben, wenn doch 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 von Delphi.Narium:

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.

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 if varibabel = true then .

Frage ja auch nicht ab: if (variabel = 1) and (1 = 1) then oder gar 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.: if UntersuchungsErgebnis = True then

Wenn True eher eine Richtigkeit oder Vollständigkeit anzeigt lasse ich das auf jeden Fall weg wie z.B. bei
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. 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.:
CheckTrue( Assigned(parameter) )
andererseits
CheckEquals(True, Testklasse.UntersuchungsErgebnis);
oder
CheckEquals(False, Testklasse.UntersuchungsErgebnis);

[Dennis07]

Um nochmal auf das Problem zurückzukommen, ich würde es sogar mit einer 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?

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 von himitsu:

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

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?
True , weil es kein False gibt oder False , weil es kein True gibt? Wenn du das entschieden hast, kannst du ja dann noch eine Initializierung unten vornehmen. Oder, wohl noch besser, vorher auf Length(AArray <> 0) prüfen und ansonsten eine Fehlermeldung ausgeben.

Zitat von himitsu:

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 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 for i := 1 to 11 do intern schonmal zu einem 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 von himitsu:

Der Witz ist, dass der Compiler die Zählvariable optimieren kann und aus eimen for i := 1 to 11 do intern schonmal zu einem 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 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 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.