Fehlertoleranz DELPHI Compiler

[Patito]

Zitat von Stevie:

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.

Um Speicherverwaltung direkt nicht. Aber das eigentliche praktische Problem ist doch, dass man Zugriffe auf bereits entsorgte Objekte verhindern möchte. Da hilft einem der GC gar nicht - bzw. dort ist einfach alles erlaubt.

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Dieses "sich keinen Kopf machen müssen" mit GC halte ich für eine reichlich naive Sichtweise.

[himitsu]

Zitat von Patito:

Dieses "sich keinen Kopf machen müssen" mit GC halte ich für eine reichlich naive Sichtweise.

Siehe meine Signatur.

Aber stimmt ... noch ein Grund, warum der "Probleme" bereiten kann.

Und die hatte ich sogar schon lange bevor das hier auftauchte:
http://www.delphipraxis.net/171824-g...i-objekte.html

[Meflin]

Zitat von Patito:

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Die Aussage ist ja in sich schon widersprüchlich; entweder ein Objekt wird noch verwendet, dann kann es aber nicht gleichzeitig tot sein. Oder aber es wird nicht mehr verwendet, dann wird es der GC auch wegräumen Ganz im Gegenteil, das Beispiel aus dem Eingangspost zeigt doch sehr schön, dass man derartige Probleme aber bei manueller Speicherverwaltung sehr wohl haben kann. Mit Garbage Collection aber halt schlicht und ergreifend nicht. Und wie du darauf kommst, mit GC liese sich schlechter Debuggen oder Testen, das würde mich ja mal interessieren...

[Medium]

Ein GC räumt erst dann Objekte weg, wenn alle Referenzen die auf sie verweisen aus ihrem Scope fallen. Zugriffe auf Referenzen die nicht im Scope liegen, sind schon durch den simplen Syntax-Check abgedeckt.

[stahli]

Zitat von Meflin:

Die Aussage ist ja in sich schon widersprüchlich; entweder ein Objekt wird noch verwendet, dann kann es aber nicht gleichzeitig tot sein. Oder aber es wird nicht mehr verwendet, dann wird es der GC auch wegräumen

Das Objekt ist tot, wenn es von der "zuständigen Stelle" freigegeben wird.
Ab dann sind Zugriffe auf das Objekt von anderer Stelle aus (Referenzen) darauf grundsätzlich fehlerhaft.
Entweder werden
a) vor kurzem noch korrekte Daten benutzt, die inzwischen aber im Projektkontext keine Gültigkeit mehr haben
b) komplett ungültige Daten benutzt, weil die Speicherstellen inzwischen überschrieben wurden
c) knallt es weil Methoden auf Grund eines überschriebenen Speichers nicht mehr ausführbar sind

Ein GC sichert ab, dass nur Problem a) entsteht. Aber eine ausreichende Lösung ist das noch nicht.
Im Spiel könnte so noch auf das Raumschiff zugeriffen werden, obwohl es eigentlich schon explodiert ist. Jetzt kann man streiten ob das besser ist als eine Exception.

[Stevie]

Zitat von Patito:

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Dieses "sich keinen Kopf machen müssen" mit GC halte ich für eine reichlich naive Sichtweise.

Wie schon andere gesagt haben, nein, so funktioniert ein GC nicht. Der GC weiß, welche Instanzen noch in Gebrauch sind (mindestens eine Referenz existiert noch). Genau aus diesem Grund gibt es auch in C# WeakReference.
Außerdem ist der GC etwas schlauer als das simple RefCounting, was COM Interfaces praktizieren (zirkuläre strong references = memleak).

[Patito]

Zitat von Meflin:

Zitat von Patito:

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Die Aussage ist ja in sich schon widersprüchlich;

Ist sie nicht. Stell Dir mal vor Du hast ein Objekt, das eine Bestellung von 100 Tonnen
nassem Beton repräsentiert - der in deinen Vorgarten gekippt werden soll.

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.

Meiner Erfahrung nach sind die QS-Werkzeuge auf der Seite des GC einfach wesentlich
schlechter.

Dass manche Leute gar nicht erst auf die Idee kommen warum man mal Objekte als erledigt
markieren will spricht Bände...

[Stevie]

Zitat von Patito:

Zitat von Meflin:

Zitat von Patito:

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Die Aussage ist ja in sich schon widersprüchlich;

Ist sie nicht. Stell Dir mal vor Du hast ein Objekt, das eine Bestellung von 100 Tonnen
nassem Beton repräsentiert - der in deinen Vorgarten gekippt werden soll.

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.

Meiner Erfahrung nach sind die QS-Werkzeuge auf der Seite des GC einfach wesentlich
schlechter.

Dass manche Leute gar nicht erst auf die Idee kommen warum man mal Objekte als erledigt
markieren will spricht Bände...

Dass man den Zustand "Bestellung erledigt" auf Speicherverwaltungsebene abhandelt, anstatt als eben das, eine Eigenschaft deiner Bestellung will mir mal gar nicht in den Kopf.

[himitsu]

Klar, man kann ja gerne ein "Erledigt" Flag in seine Klassen einbauen.
Das muß dann aber auch entweder extern überall geprüft werden, oder man prüft es intern und baut in jede Methode, Getter und Setter die Prüfung ein.
(früher reichte es mal, wenn das Objekt dA freigegeben wurde, wo man Free aufrief. )

[Medium]

Überhaupt habe ich den Eindruck, dass ein GC fast nur dann zu diesen ominösen Problemen führen kann, wenn man einen Speichermanager fälschlicherweise missbraucht um Geschäftslogik zu implementieren.