Delphi-PRAXiS
Seite 5 von 5   « Erste     345   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   Fehlertoleranz DELPHI Compiler (https://www.delphipraxis.net/171828-fehlertoleranz-delphi-compiler.html)

Medium 28. Nov 2012 15:42

AW: Fehlertoleranz DELPHI Compiler
 
Zitat:

Zitat von Patito (Beitrag 1193440)
Dann gibt es auf einmal in Programmen überhaupt keine Notwendigkeit mehr auf Zugriffe auf ungültige Objekte überhaupt zu testen "wegen der Geschäftslogik in realen Softwaresystem".

Konstruiere uns doch am besten mal ein Beispiel, bei dem dieses Verhalten auftreten würde. Ein Stückchen Code, der einfach einen kleinen Beispielfall demonstriert, in dem die Gefahr eines hypothetischen GCs wie geschildert zur Funktionsstörung führt, welche bei non-GC Umgebungen nicht passieren kann. Und zwar so, dass es softwaretechnisch "vertretbar" ist, auch keinen fiesen Hack mit Pointerverdreherei oder ASM-Kunststückchen.
Ich kann mir im Moment einfach keinen Fall vorstellen, wäre aber sicherlich interessiert. Gute Chance zur Meinungsänderung bei mir besteht immer, aber ich brauche guten Grund :)

DeddyH 28. Nov 2012 15:54

AW: Fehlertoleranz DELPHI Compiler
 
Sind wir eigentlich noch beim Thema? :gruebel:

BUG 28. Nov 2012 17:04

AW: Fehlertoleranz DELPHI Compiler
 
Zitat:

Zitat von Patito (Beitrag 1193341)
Zitat:

Zitat von BUG (Beitrag 1193279)
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:

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".


Zitat:

Zitat von Patito (Beitrag 1193385)
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.

Furtbichler 28. Nov 2012 17:39

AW: Fehlertoleranz DELPHI Compiler
 
Zitat:

Zitat von Patito (Beitrag 1193191)
...NP-Vollständigen Problems (mit entsprechend endloser Rechenzeit)...

Zitat:

Zitat von BUG
...einen Haufen saure Gurken dort hingeschüttet, wo der entfernte Betonhaufen stand.

Nicht, das ich elementare Zitate aus dem Zusammenhang werfen will...
Zitat:

Zitat von DeddyH (Beitrag 1193455)
Sind wir eigentlich noch beim Thema? :gruebel:

Ich denke, nicht.

Meflin 28. Nov 2012 18:21

AW: Fehlertoleranz DELPHI Compiler
 
Zitat:

Zitat von Patito (Beitrag 1193440)
Als nächstes kommt ihr noch auf die Idee und schreibt für C# einen Meta-GC, der verhindert, dass dort
Weak-References jemals auf ungültige Targets verweisen können...

Seriously? Weak References sind etwas, was man annähernd nie selbst verwendet, und selbst wenn man sie verwendet, tut man das annähernd nie direkt, da einem moderne Umgebungen da durchaus Konstrukte zur einfacheren Handhabung bereitstellen, z.B. durch Weak-Referenced Dictionaries, deren Einträge automatisch entfernt werden, wenn das referenzierte Objekt nicht mehr existiert. Das mag dem gemeinen Delphi-Entwickler jetzt schon fast wie schwarze Magie vorkommen, es lebt sich aber sehr entspannt damit :roll: Und das ist jetzt dein ganzes Argument, dass Garbage Collection das Problem des Zugriffes auf ungültige Referenzen im Großen und Ganzen nicht löst? Na dann...
Zitat:

Comedy vom feinsten...


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:00 Uhr.
Seite 5 von 5   « Erste     345   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz