Schleifenvariable beschreiben, ...

[Corpsman]

Guten Morgen,

Ich höre ja gerade eine Vorlesung über Konzepte von Programmiersprachen.

Und unser Prof zeigt uns immer mal wieder echt "Überraschende" dinge.

Das Konstanten keine Konstanten sind hatte ich ja auch schon mal geschrieben.

Heute zeige ich euch wie man Schleifenvariablen werte zuweisen kann.

Ja richtig gelesen, das geht. Obwohl es eigentlich nicht erlaubt ist.

Und wie auch schon bei den Konstanten lautet der Trick hier wieder , POINTER.

Es scheint als habe Delphi ( zumindest D5Pro ) keinerlei Pointer Optimierung, bzw. Pointer Prüfungen.

Folgender Code ist in D5 Legal und sorgt für eine Endlosschleife.

Testet doch bitte in euren D5 versionen ob der Code Legal ist und ob das selbe passiert .

Delphi-Quellcode:

Procedure TForm1.Button1Click(Sender: TObject);
Var
  x: Integer;
  p: ^integer;
Begin
  p := @x;
  For x := 0 To 3 Do Begin
    showmessage(inttostr(x));
    p^ := 1;
  End;
End;

Also aufgepasst. Jeder der sich ein Programm schreibt das Pointer benutzt. Eure schleifen könnten evtl. ewig laufen *g*

[jaenicke]

Wenn du mit Pointern herumspielst, dann musst du auch wissen was du tust. Wenn nicht, dann hast du eben Pech.

[himitsu]

Zitat:

Das Konstanten keine Konstanten sind hatte ich ja auch schon mal geschrieben.

nicht alle

Zitat:

Heute zeige ich euch wie man Schleifenvariablen werte zuweisen kann.
Ja richtig gelesen, das geht. Obwohl es eigentlich nicht erlaubt ist.

und das weiß ich schon lange, aber sowas macht man nicht, denn ein kleiner Fehler und die Abbruchbedingung der Schleife wird nicht mehr erfüllt.

Hatte ich mal, als ich eine Schleife in 3er-Schritten zählen lassen wollte

quasi:

Delphi-Quellcode:

For x := 0 to 10 step 3 do
  ...

also

Delphi-Quellcode:

For x := 0 to 10 do Begin
  ...
  Inc(PInteger(@x), 3);
End;

und wer richtig hinsieht, wird schnell erkennen, daß die 10 nie nicht getroffen wird und es somit zum Überlauf kommt - 0, 3, 6, 9, 12, 15... - nachdem der Integer-Wertebereich dann zum drittenmal durchlaufen wurde, dann trifft er hier zufällig mal die 10

Und ja, Delphi (alle Versionen) hat da keine Pointer-Prüfung drin.

[edit]
jatzt mach ich schon statt Quote-Tags überall Delphi-Tags

[mkinzler]

Saubere Programmierung scheint mir sowieso out zu sein

[himitsu]

Zitat von mkinzler:

Saubere Programmierung scheint mir sowieso out zu sein

sagen wir es mal so, ich bin vor 4 oder 5 Jahren mal auf diesen "Trick" gekommen und ich nutze es in keinem aktiven Programm mehr.

Auch wenn ich in anderen Dingen wohl auch nicht sooooo braf bin und den offiziellen Weg geh.

[mkinzler]

Hallo Frank, du hast dich einfach so dazwischen geschoben, die Aussage war nicht an dich gerichtet.
Es gibt wohl Probleme, die "dreckig" gelöst werden wollen, bzw bei denen eine solche Lösung im Moment besser (erscheint) oder hilft scnhell weiterzukommen. in den meisten Fällen ist es aber besser eine saubere Lösung zu finden.
Dazu sollte man aber genau wissen, was man macht und im Hinterkopf behalten, dass bei einer neuen version des Compilers oder sogar nach einem Patch die ganze Sache nicht mehr funktionieren könnte.

[Corpsman]

@jaenicke

Irgendwie hab ich das Gefühl, das ich misverstanden wurde.

Mir ist schon klar was Pointer können, und was sie anrichten. Dieser Thread galt mehr als !Achtung! Pointer können auch viel Blödsinn anstellen.

Gerade in der Theorie ist es wichtig das man weis, das eine Schleife immer Terminiert. Und das hier gezeigte Beispiel sollte lediglich zeigen, das dies in Delphi per se nicht der Fall ist.

[Luckie]

Zitat von Corpsman:

das eine Schleife immer Terminiert. Und das hier gezeigte Beispiel sollte lediglich zeigen, das dies in Delphi per se nicht der Fall ist.

Wie kommst du darauf, dass eine Schleife immer terminiert? bei einer while-Schleife muss nur die Abbruchbedingung nicht stimmen und die Schleife wird nicht terminieren.

Davon mal abgesehen, war dein Beispiel wohl schon allgemein bekannt.

[Reinhard Kern]

Zitat von himitsu:

[

Delphi-Quellcode:

For x := 0 to 10 do Begin
  ...
  Inc(PInteger(@x), 3);
End;

und wer richtig hinsieht, wird schnell erkennen, daß die 10 nie nicht getroffen wird und es somit zum Überlauf kommt - 0, 3, 6, 9, 12, 15... - nachdem der Integer-Wertebereich dann zum drittenmal durchlaufen wurde, dann trifft er hier zufällig mal die 10 :angel2:

Hallo,

das ist aber unsaubere Programmierung durch den Compiler selbst: jeder Anfänger weiss oder merkt es mal, dass man Abbruchbedingungen möglichst nicht mit =, sondern mit < oder > machen sollte, Grund siehe oben. Ich nenne das defensives Programmieren.

Aber wie schon bemerkt, sowas ist ja out.

Gruss Reinhard

[himitsu]

For hat aber anscheinend ein = als Abbruchbedingung ud als Startbedingung ein >= bzw. <=

und jupp eine kleines While-Schleifchen und alles ist Gut