Fehlertoleranz DELPHI Compiler

[stahli]

@Bernhard

Ein Bug ist es nicht, eher ein konzeptionelles Problem.
Hier (und an anderen Stellen) wurde das schon mal diskutiert: http://www.delphipraxis.net/159095-r...e-objekte.html

Das neu eingeführte Referenzcounting für Objekte (siehe aktueller Thread) könnte evtl. etwas Abhilfe schaffen. Allerdings würde dann das Objekt noch im Speicher bleiben, obwohl es eigentlich bereits aufgelöst sein sollte. Im Grunde würde das Überschreiben des Speichers verhindern und Deine "Glückstreffer" sicher gestalten.
Es würde also nicht "knallen", aber Du würdst mit einem Objekt arbeiten, das eigentlich gar nicht mehr da ist.

Um den Verweis zu nilen braucht es irgendeinen Observer, der standardmäßig im Delphi leider nicht existiert.

[bernhard_LA]

@ Stali :
mit eigentlich ungültigen Werte noch arbeiten zu können halte ich für nicht sehr geschickt, man sollte das Problem an der Wurzel packen und auch dort sofort beheben.




FASTMM4 und Madshi können zwar nach dem Auftreten solle Probleme anzeigen, ich fände es aber eine bessere Lösung wenn mann beim Übersetzen auf solche "Handwerklichen" Fehler den Code zu untersuchen könnte

[Sir Rufo]

Zitat von bernhard_LA:

@ Stali :
mit eigentlich ungültigen Werte noch arbeiten zu können halte ich für nicht sehr geschickt, man sollte das Problem an der Wurzel packen und auch dort sofort beheben.

FASTMM4 und Madshi können zwar nach dem Auftreten solle Probleme anzeigen, ich fände es aber eine bessere Lösung wenn mann beim Übersetzen auf solche "Handwerklichen" Fehler den Code zu untersuchen könnte

Ist das jetzt der Ruf nach "Betreutem Programmieren"?

Wie lange soll denn der Compiler auf dem Code rumnudeln bis er alle möglichen handwerklichen Fehler gefunden hat?

Das ist ein klarer Fall für einen Test mit DUnit aber nicht für den Compiler

[Patito]

Zitat von bernhard_LA:

FASTMM4 und Madshi können zwar nach dem Auftreten solle Probleme anzeigen, ich fände es aber eine bessere Lösung wenn mann beim Übersetzen auf solche "Handwerklichen" Fehler den Code zu untersuchen könnte

Ein Syntax-Check entspräche in etwa der Lösung eines NP-Vollständigen Problems (mit entsprechend endloser Rechenzeit), oder der Check funktioniert eben nur "manchmal".

Mit FastMM findet man rein praktisch 99.99% aller Probleme. Was willst Du mehr?

[BUG]

Zitat von Patito:

Ein Syntax-Check entspräche in etwa der Lösung eines NP-Vollständigen Problems (mit entsprechend endloser Rechenzeit), oder der Check funktioniert eben nur "manchmal".

Der Syntax-Check funktioniert (afaik) in Linearzeit, sonst könntest du lange auf den Compiler/Lexer warten.

Die Korrektheit eines (Turing-)Programms zu prüfen kann (je nach genauer Aufgabe) schwer bis unmöglich (Halteproblem) sein.
Es gibt allerdings durchaus auch brauchbare statische Analysemethoden für Quellcode. Als einfaches bekanntes Beispiel: Typprüfung.


Sei etwas vorsichtiger mit Begriffen wie "NP-vollständig".

[Furtbichler]

Wann kommt endlich neben dem Syntaxcheck auch der Semantikcheck?

[jaenicke]

Zitat von Furtbichler:

Wann kommt endlich neben dem Syntaxcheck auch der Semantikcheck?

Den gibt es ja in Oxygene schon. Da werden typische Fehler / unsaubere Techniken erkannt.

[Patito]

Zitat von BUG:

Sei etwas vorsichtiger mit Begriffen wie "NP-vollständig".

Warum?

[BUG]

Zitat von Patito:

Zitat von BUG:

Sei etwas vorsichtiger mit Begriffen wie "NP-vollständig".

Warum?

Weil ich ungünstig finde, wenn die Begriffe ohne groß nachzudenken falsch verwendet werden. Beispiel:

Zitat von Patito:

Ein Syntax-Check entspräche in etwa der Lösung eines NP-Vollständigen Problems (mit entsprechend endloser Rechenzeit), oder der Check funktioniert eben nur "manchmal".

Zitat von Patito:

Jetzt willst Du dieses Objekt löschen - und alle Zugriffe auf das Objekt sollen
zu Fehlern führen. Mit GC ist das ein Krampf - man muss da quasi händisch das Rad der
Access Violation neu erfinden.

Die Access Violation ist bei deinem Vorgehen auch nicht garantiert.
Um beim Bild zu bleiben: Jemand hat einen Haufen saure Gurken dort hingeschüttet, wo der entfernte Betonhaufen stand. Nun willst du den Betonhaufen wegschaufeln und haust die armen sauren Gurken in den Müll.

[stahli]

Zitat von bernhard_LA:

@ Stahli :
mit eigentlich ungültigen Werte noch arbeiten zu können halte ich für nicht sehr geschickt, man sollte das Problem an der Wurzel packen und auch dort sofort beheben.

Das Problem liegt halt in der EDV.
Wenn ein Dritter mein Fahrrad klaut kann ich mich am nächsten Tag nicht mehr drauf setzen.

Wenn irgendwer mein Objekt zerstört, dann sind die Speicherzellen halt ja noch dort und irgendwelche Zeiger können auf die Stelle verweisen.
Eine vollständig automatische Zeigerbereinigung ist undenkbar - nicht mal für mich!

Aber wenn ich dem Compiler sagen könnte: "Richte mal für mich eine Überwachung meines Fahrrades ein und setze F1 und F2 auf null, wenn das Fahrrad aufgelöst wird.", das wäre schon eine nette Sache und würde dem Programmierer eigene Obser-Lösungen oftmals abnehmen können.
Natürlich hilft das Konstrukt auch nur dann, wenn das Fahrrad regulär freigegeben wird, aber nicht, wenn eine Walze drüber fährt (bzw. der Speicher irgendwie fehlerhaft überschrieben wird).