If Anweisung mit 2 Bedingungen?

[Khabarakh]

Zitat:

Zitat von Palando

Zitat:

Zitat von rantanplan99

Mit logischen Verknüpfungen ist das machbar.
.. AND ..
.. OR ..

Gibt es eigentlich auch ein XOR? Weil einfach "XOR" ging bei mir glaube ich nicht...


(XOR = die Schleife wird nur ausgeführt, wenn die eine Bedingung true und die andere false ist. Wenn beide true sind, oder beide false, dann wirds nicht gemacht.)

Natürlich gibt es in Delphi xor. Und es gibt in Delphi auch eine Hilfe, die selbst in D2005 nach der kurzen Eingabe von "xor" folgendes ausspuckt :wink: :

Zitat:

Zitat von F1

xor Exklusive Disjunktion A xor B

Den unären Operator not gibt es übrigens auch.

[BenjaminH]

Zitat:

Zitat von Palando

Gibt es eigentlich auch ein XOR?

Ja, das gibt es!

Delphi-Quellcode:

If true xor false Then

[Palando]

Zitat:

Zitat von BenjaminH

Zitat:

Zitat von Palando

Gibt es eigentlich auch ein XOR?

Ja, das gibt es!

Delphi-Quellcode:

If true xor false Then

Dann war ich, wo ich das probiert habe, wohl einfach unfähig.

Dankeschön :)

edit: Auch danke an Khabarakh... Ich hatte eben kein Delphi da ums nachzukucken, kam mir nur, als ich den Thread gelesen habe...

[hardy1234]

Zitat:

Zitat von malo

@hardy1234: Wegen den Schleifen: Es waren bestimmt die if-Abfragen gemeint ;)
Bei der ersten Variante fehlen jedoch die Klammern.


Die zweite Variante halte ich (besonders für Anfänger) viel zu kompliziert.

Was mich bei Schleifen in diesem Fall stört: Der Code wird IMMER WIEDER ausgeführt. Deshalb sind es auch Schleifen. Man müsste künstlich die Bedingung unterbrechen oder ein Break einbauen, was nicht so schön ist.

Pfui, break. wer macht denn sowas. der witz an while do begin ... end und repeat ... until ist es ja gerade, das man sich den break schenken kann. Es gibt da noch das Paradigma des middle-check, mit dem man den break leicht umgeht, nämlich so:

Delphi-Quellcode:

function TestIrgendwas(var i: integer;...): boolean;
var
  good: boolean;
begin
  i:= 0; good:= false;
  while (i <= maxloop) and not(good) do begin
    good:= {*** hier irgendeine expression ***}
    if not(good) then inc(i);
  end;
  if good then begin
    {*** hier die nachverarbeitung im Erfolgsfall, wenn nötig ***}
    {*** falls das ne Liste ist, hat man nun auch den richtigen index. ***}
    {*** was will man mehr? ***}
  end;
  {*** falls boolean-function, wie hier  ***}
  Result:= good;
end;

Der charme der geschichte dürfte klar sein. die schleife läuft genauso lange bis etwas bestimmtes gefunden wurde und dann ist schluß. da man die expression in der mitte der schleife jeweils neu setzt steuert diese die schleife und sorgt für die Abbruchbedingung. Wie man sieht kein "break". Da hab ich schon richtig komplexe tests damit duchgeführt und das klappt immer. Nebenbei ist es äußerst elegant programmiert. Die Abbruchbedingungen lassen sich ja genauso gut auch mit weiteren funktionen auslagern, die dürfen ja auch lokal vereinbart sein. Hätte ich solche dinger wie break oder noch schlimmer goto verwendet, hätte ich nicht mal das 1ste Semester überstanden. Derlei schweinereien sind den Basic- und Script-Programmierern vorbehalten...

[alzaimar]

Es ist nichts Verwerfliches an einem 'break', im Gegenteil: Es macht den Code i.a. wesentlich lesbarer. Die Diskussion um break, exit und goto ist so alt wie die Konstrukte selbst. Da das sehr viel mit Glauben zu tun hat, sollte jeder selbst entscheiden, was er wie einsetzt: Selbst goto's haben ihre Berechtigung.

Einzige Voraussetzung: Die Lesbarkeit und m.E. die Performance sind entscheidend.

Natürlich kommt man ohne break und goto aus, aber es geht ja auch ohne prozeduren, funktionen, units und die VCL. Nur, wieso sollte ich auf etwas verzichten? Und das erste Semester hättest Du auch mit gotos und breaks überstanden... Sofern Du sie richtig einsetzt.

[hardy1234]

Zitat:

Zitat von alzaimar

Und das erste Semester hättest Du auch mit gotos und breaks überstanden... Sofern Du sie richtig einsetzt.

War bei uns strengstens verboten, mit folgendem Hintergrund:

Wer goto, break und Konsorten verwendet, hat über seinen Programmcode nicht genügend nachgedacht. (Punkt)

Aus eigener Erfahrung, speziell nach der Durchsicht von fremden Code kann ich diese Aufassung nur teilen. Der Spagetti-Code entsteht meist aus dem einfachen Grund, das man drauflos proggt und dann erst nachdenkt. Irgendwo in der Mitte schlägt dann die Logik gnadenlos zu und es bleibt nur noch der "Notausstieg" per goto und ähnlichem. Und erzähle mir keiner, er wäre nicht gelegentlich versucht, sich auf diese Weise aus der Affäre zu ziehen.

Wie das allerdings zur Lesbarkeit beitragen soll, bleibt wohl dein Geheimnis. Das kenn ich aus BASIC-Zeiten anders. Lesbarkeit erzeugt man durch sprechende Variablen-Namen und Remarks, mit GOTO sicher nicht.

Ich hab selbst mal mit BASIC angefangen, da ging es nun garnicht anders. Ich habe 3 Kreuze gemacht, als es Turbo-PASCAL zu erschwinglichen Preisen gab. Endlich diesen Goto-Scheiß und die globalen Variablen weg...