Fehlertoleranz DELPHI Compiler

[Patito]

Zitat:

Zitat von Stevie (Beitrag 1193196)

Klassischer Fall von Objekt über seine lifetime hinaus benutzt.

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

Verbirgt sich dahinter eigentlich praktische Technik, oder liegt hier die Betonung eher auf "rumfuhrwerken"??

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1193196)

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

Oder man benutzt einfach konsequent das oben bereits genannte FreeAndNil, dann knallt es auch direkt, es sei denn es handelt sich um eine lokale (und daher nicht automatisch initialisierte) Variable.

Einziger Fallstrick dabei ist, wenn man den Code später auf Interfaces umstellt. An FreeAndNil kann man nämlich auch Interfaces übergeben, deshalb knallt es leider erst beim Aufruf.

[Sir Rufo]

Zitat:

Zitat von jaenicke (Beitrag 1193231)

Oder man benutzt einfach konsequent das oben bereits genannte FreeAndNil, dann knallt es auch direkt, es sei denn es handelt sich um eine lokale (und daher nicht automatisch initialisierte) Variable.

In diesem speziellen Fall hilft das nicht, denn TForm2 setzt mit FreeAndNil( bDataClass ) nicht TForm1.aDataClass auf nil und der Speicherbereich wird auch nicht damit geleert/überschreiben, sondern einfach nur wieder in den Topf geworfen.

[Stevie]

Zitat:

Zitat von Patito (Beitrag 1193228)

Zitat:

Zitat von Stevie (Beitrag 1193196)

Klassischer Fall von Objekt über seine lifetime hinaus benutzt.

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

Verbirgt sich dahinter eigentlich praktische Technik, oder liegt hier die Betonung eher auf "rumfuhrwerken"??

Ich meinte damit, dass man sich dort (bis auf Ausnahmen) keinen Kopf um Speicherverwaltung machen muss - was ich hier nicht bewerten möchte, da es sowohl Vor- als auch Nachteile mit sich bringt.

Zitat:

Zitat von jaenicke (Beitrag 1193231)

Oder man benutzt einfach konsequent das oben bereits genannte FreeAndNil, dann knallt es auch direkt, es sei denn es handelt sich um eine lokale (und daher nicht automatisch initialisierte) Variable.

Einziger Fallstrick dabei ist, wenn man den Code später auf Interfaces umstellt. An FreeAndNil kann man nämlich auch Interfaces übergeben, deshalb knallt es leider erst beim Aufruf.

FreeAndNil (am besten noch mit ganz vielen

Delphi-Quellcode:

if Assigned(...)

garniert) kaschiert nur noch mehr eine mögliche Ahnungslosigkeit, wer für diese Instanz eigentlich zuständig ist.
Aber lasst uns die FreeAndNil Diskussion gleich wieder begraben, das hatten wir schon an anderer Stelle zu genüge ;)

[Aphton]

Zitat:

Zitat von bernhard_LA (Beitrag 1193177)

Delphi-Quellcode:

  aForm2.Create(...)

Steht das wirklich so dort?

[Furtbichler]

Zitat:

Zitat von Stevie (Beitrag 1193241)

FreeAndNil (am besten noch mit ganz vielen

Delphi-Quellcode:

if Assigned(...)

garniert) kaschiert nur noch mehr eine mögliche Ahnungslosigkeit, wer für diese Instanz eigentlich zuständig ist.

Sehr schön erklärt.

Wem gehört die Instanz? Wir haben es hier mit einem globalen Objekt zu tun, quasi ein Singleton, der seine Singularität durch das Kopieren der Instanz erhält. Wir wissen, das so etwas ziemlich 'böse' ist (eigentlich ist es nur ein sehr wackeliges Design) und mit Samthandschuhen anzufassen, ach was rede ich, komplett zu vermeiden ist.

Wozu gibt es in Delphi das Konzept der Datenmodule? Die sind ja nicht auf TDataSets beschränkt. Das Konzept ist 25 Jahre alt (soweit ich mich erinnere) und sollte vermeiden, das Daten wüst hin und her verschoben und übergeben werden.

Letztendlich verwaltet dann ein Datenmodul die DataClass-Instanz, erzeugt sie und gibt sie wieder frei. Es muss -per Architektur- einfach wissen, wann es sich verabschieden darf.

Und wenn man dann auch noch damit aufhört, Objektinstanzen zu kopieren, sondern nur als Parameter zu übergeben, kann der beschriebene Bug (der ja keiner is) gar nicht auftreten.

[BUG]

Zitat:

Zitat von Patito (Beitrag 1193191)

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?:stupid:

[Patito]

Zitat:

Zitat von BUG (Beitrag 1193279)

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

Warum?

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1193287)

Wann kommt endlich neben dem Syntaxcheck auch der Semantikcheck?:stupid:

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