AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Fehlertoleranz DELPHI Compiler

Ein Thema von bernhard_LA · begonnen am 27. Nov 2012 · letzter Beitrag vom 28. Nov 2012
Antwort Antwort
Seite 2 von 5     12 34     Letzte »    
Patito

Registriert seit: 8. Sep 2006
108 Beiträge
 
#11

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 14:16
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"??
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.572 Beiträge
 
Delphi 11 Alexandria
 
#12

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 14:23
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#13

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 14:42
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#14

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 15:34
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.


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 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
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (27. Nov 2012 um 15:40 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Aphton
Aphton

Registriert seit: 31. Mai 2009
1.198 Beiträge
 
Turbo Delphi für Win32
 
#15

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 15:36
  aForm2.Create(...)
Steht das wirklich so dort?
das Erkennen beginnt, wenn der Erkennende vom zu Erkennenden Abstand nimmt
MfG
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#16

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 19:54
FreeAndNil (am besten noch mit ganz vielen 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.
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#17

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 21:05
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".
Intellekt ist das Verstehen von Wissen. Verstehen ist der wahre Pfad zu Einsicht. Einsicht ist der Schlüssel zu allem.

Geändert von BUG (27. Nov 2012 um 22:37 Uhr)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#18

AW: Fehlertoleranz DELPHI Compiler

  Alt 27. Nov 2012, 22:17
Wann kommt endlich neben dem Syntaxcheck auch der Semantikcheck?
  Mit Zitat antworten Zitat
Patito

Registriert seit: 8. Sep 2006
108 Beiträge
 
#19

AW: Fehlertoleranz DELPHI Compiler

  Alt 28. Nov 2012, 10:14

Sei etwas vorsichtiger mit Begriffen wie "NP-vollständig".
Warum?
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.572 Beiträge
 
Delphi 11 Alexandria
 
#20

AW: Fehlertoleranz DELPHI Compiler

  Alt 28. Nov 2012, 10:34
Wann kommt endlich neben dem Syntaxcheck auch der Semantikcheck?
Den gibt es ja in Oxygene schon. Da werden typische Fehler / unsaubere Techniken erkannt.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 5     12 34     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:24 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz