Schleifen --> verwirrt

[Warf]

Bei mir (fpc 3.0.4, OSX 10.13.4 High Sierra) kommt ohne range check 0 raus. Etwas besser, aber auch nicht gut. Hab vielleicht andere Voreinstellungen. Mit range check (-Cr) kommt ein run time error. In schönem Pascal code würde man aber auch einen subrange typ 20..50 deklarieren und beim array und bei i verwenden. Dann gibt es auch schon prompt einen Fehler beim Kompilieren. Zeigt das Beispiel nicht eher, dass man in Pascal auch C-ähnlich programmieren kann, sich dann aber auch mit den gleichen Problemen rumschlagen muss.

x86_64 Kompiliert? ich kompiliere einfach über die Konsole: fpc -g test.pas ist standardmäßig x86-64

[mischi]

x86_64 Kompiliert? ich kompiliere einfach über die Konsole: fpc -g test.pas ist standardmäßig x86-64

Yep. 64bit. 32bit ist aber auch gleich. Auch über die Konsole, aber fpc mit fink installiert. Sollte aber eigentlich egal sein. Das Problem ist natürlich auch bei dem Ergebnis, dass wild in die Pampa geschrieben wird, ohne dass es kracht.

[m.fuchs]

Oder sind dir diese szenarien auch zu abstrakt?

Sie sind zumindest alle nicht mal annähernd gekapselt und fern jegliche durchdachter Architektur. Wenn ich was kaputt bekommen will, dann kann ich das problemlos auch mit Pascal machen.
Wenn ich aber vor dem Entwickeln plane, dann kann ich die meisten solcher seltsamen Probleme verhindern.

Mach gerne ein Praxisbeispiel auf, dann aber bitte in einem neuen Thread.

[Warf]

Oder sind dir diese szenarien auch zu abstrakt?

Sie sind zumindest alle nicht mal annähernd gekapselt und fern jegliche durchdachter Architektur. Wenn ich was kaputt bekommen will, dann kann ich das problemlos auch mit Pascal machen.
Wenn ich aber vor dem Entwickeln plane, dann kann ich die meisten solcher seltsamen Probleme verhindern.

Mach gerne ein Praxisbeispiel auf, dann aber bitte in einem neuen Thread.

Hab ich gemacht. Habe da 2 Beispiele die sich an alle regeln von OOP halten und es trotzdem schaffen die memory des anderen Objektes zu überschreiben, ohne das die Objekte voneinander wissen.

[Mathias]

Das Realzahlenproblem kann msn mit einer while do Schleife umgehen.

Jetzt musste ich erst einmal einen Moment nachdenken was du meinst. Du beziehst dich auf die Real-World Probleme nicht auf Realzahlen.

Klar kann man das in einer while..do-Schleife lösen, man kann auch komplett auf for..to..do verzichten. Man könnte auch label, goto und if verwenden um das alles abzubilden.
Die Frage ist nur Warum?

So abwägig ist die gar nicht, auf der Assembler-Ebene wird alles mit springen gelöst. Eine for-Schleife ist eigentlich nur ein Komfort einer Hochsprache.

[m.fuchs]

Man könnte auch label, goto und if verwenden um das alles abzubilden.
Die Frage ist nur Warum?

So abwägig ist die gar nicht, auf der Assembler-Ebene wird alles mit springen gelöst. Eine for-Schleife ist eigentlich nur ein Komfort einer Hochsprache.

<Loriot>Ach?</Loriot> Es ist vollkommen abwegig. Ich benutze eine Hochsprache um nicht wilde Konstrukte zu verwenden, die ich mit Assembler hätte.
Und ich benutze Pascal um lesbaren Code zu schreiben. Also setze ich die Möglichkeiten die diese Sprache dafür hat auch ein.

[mischi]

Bei Goto fällt mir noch eine schöne Geschichte ein: Uralter code in Fortran mit recht vielen IFs und GOTOs. Umgeschrieben auf modernes if then else. Eigentlich nur um besser lesbaren Code zu haben. Positiver Seiteneffekt: Der Code wurde deutlich schneller. Offensichtlich konnte der übersichtlichere Code auch vom Compiler besser optimiert werden.