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

[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.

[Dennis07]

Aber wenn es dich so krass stört, die Ergebnisvariable als Schleifenvariable zu verwenden, dann bitte...

Delphi-Quellcode:

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

[hoika]

Hallo,

Zitat:

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.

Das ist nicht ganz korrekt.
Wenn die Schleifenvariable innerhalb der Schleife nicht benutzt wird, optimiert das der Compiler,
weil ein Compare mit 0 als Endergebnis der Schleifenvariable schneller ist.

Wird die Schleifenvariable innerhalb der Schleife benutzt, zählt der "Compiler richtig".

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.