wenn man in Delphi mit einem zu große Index auf ein Array zugreift.

Ich kann kein Delphi, will es nicht extra installieren, möchte es aber dennoch gerne wissen... Also ich meine: Ein Array "feld" wurde so deklariert, dass es 5 Integerwerte speichern kann. Wie was passiert in Delphi, auf des Feld mit den Index 99 zugreifen würde?

Danke!

Gruß
corgano

Falls die Option aktiv ist, solle es "Fehler bei Bereichsprüfung" sein. Ansonsten eben merkwürdiges Verhalten oder eine Zugriffsverletzung.

Hab ich das richtig verstanden: Wenn beim Compiler die richtige Option angewählt wurde kommt "Fehler bei Bereichsprüfung" - ansonsten "Runtime Error", oder wer weiß was...

Danke!
Corgano

PS: Macht es nicht Sinn dies Option immer anzuwählen?

Hallo,

corgano hat folgendes geschrieben :

Macht es nicht Sinn dies Option immer anzuwählen?

Nur während der Entwicklungsphase sollte man die Optionen Range checking (Feldgrenzen prüfen) und Overflow checking (Arithmetiküberlauf prüfen) einschalten.
Soll das Programm eine hohe Ausführungsgeschwindigkeit haben (zeitkritische Berechnungen mit Feldern u.ä.), so ist besser vor der abschließenden Compilierung die Optionen auszuschalten, da ein Programm mit den eingeschalteten Kontrollen langsamer läuft.
Allerdings darf man eben keine Feldgrenzen überschreiten.

corgano hat folgendes geschrieben :

Ich kann kein Delphi, will es nicht extra installieren, möchte es aber dennoch gerne wissen...

Wissensdurst ist immer schön. Aber dennoch: Wozu brauchst Du denn die Information?
Und Du willst es nicht installieren, d.h. Du hast eine Lizenz?! Warum willst Du es dann nicht versuchen?

Beste Grüße
Mathematiker

Danke, Mathematiker - hab so etwas vermutet.

Wozu? Ich habe neulich versucht jemanden auf diesen typischen Fehler beim Umgang mit Arrays hinzuweisen. In Java lautet dann die Fehlermeldung ArrayIndexOutOfBoundsException, in C# IndexOutOfRangeException - nur auf die Rückfrage "und in Delphi?" musste ich passen. Da dachte ich mir: Frag doch mal die Experten...

Nochmals Danke!

PS: Hab auch gleich dabei gelernt. Wenn mir jemand jammert: "Das Programm zeigt nur Runtime Error!", dann sollte derjenige beim Compiler entsprechende Warn-/Prüfoptionen anwählen, damit es etwas verständlicher wird...

Ich möchte Mathematiker in einem Punkt widersprechen: Range und Overflowchecks usw. sollten unbedingt immer eingeschaltet sein, mit einer einzigen Ausnahme: Es ist ein ansonsten schon optimierter Code, der sehr sehr zeitkritisch ist z. B. weil er in einer innersten Schleife außerordentlich oft durchlaufen wird.

Meine Begründung: Man sehe sich einmal mit dem Debugger (CPU-Fenster) an, welche Arbeit ein Konstrukt wie feld1[i].subfeld2[j].x der CPU macht. Und dann soll ja mit dem x auch noch gearbeitet werden. Da kommt es auf die mit INTEGER-Arithmetik zu erledigenden Abfrage der Grenzen für i und j nicht an. Wichtig ist allerdings eine saubere Behandlung der Exceptions. Der Gewinn an Sicherheit ist aber enorm. Es ist ja ein bekannter Virenangriff, ein Feld der Länge 10 (z. B.) anzukündigen und dann meher als 10 Zeichen zu senden. Ab dem 11. Zeichen steht dann Schade-Code.

Übrigens ist die Rakete Ariane 5 (oder 4 ?) wegen eines Zahlenüberlaufes abgestürzt.

Gruß
GueAck

Das sind schnell mal 5-10% Geschwindigkeitsverlust, deshalb halte ich wenig davon das einfach so prophylaktisch einzuschalten. Das ist als ob du nur mit aufgeblasenem Airbag Auto fährst, weil dann im Falle eines Unfalls weniger passieren kann...

Denn es gibt ja zwei Möglichkeiten:
- Der Code ist fehlerhaft. Dann hilft auch die Exception nicht viel, denn den Fehler behebt diese nicht. Man findet den Fehler nur besser, aber dafür gibt es ja die Debug-Konfiguration, Unit-Tests usw.
- Der Code ist nicht fehlerhaft. Dann braucht man die Prüfung erst Recht nicht.

Ich halte sehr viel davon dies alles prolyfaktisch einzuschalten.
10% Performance-Verlust interessieren mich wirklich nicht, wenn deshalb ein mal pro Jahr eine Fehlbuchung im Umfang von 0,5-2 MIO verhindert wird.
Wenn ich Performance will nehm ich Assembler. Und kenne die Risiken.

Mit einem Kunden wurde bei Überarbeitung des bestehenden Codes vertraglich exakt dies vereinbart: Einschaltung aller Compiler-Prüfungen. Wenn das bisher "meist korrekt funktionierende" Programm 5 Mal am Tag abschmiert und die Mitarbeiter sich deshalb beklagen ist das egal. Wenigstens kommt man dann endlich den Programmierfehlern der letzten 10 Jahre auf die Spur.

> Denn es gibt ja zwei Möglichkeiten:
> Der Code ist fehlerhaft.
ist er immer. zumindest meiner.
> Der Code ist nicht fehlerhaft. Dann braucht man die Prüfung erst Recht nicht.
Habe ich bisher noch nicht erlebt außer wenn er weniger als 100 Zeilen hatte.

Das ist nun nicht böse gemeint sondern Erfahrung.

Natürlich ist jeder Code irgendwo fehlerhaft.

Aber meistens ist die Notwendigkeit für solche Compilerschalter im Release eher ein Zeichen für fehlende Unittests etc., denn gerade solche Fehler fallen dabei zu einem großen Teil auf.