Umgang mit Interfaces

[himitsu]

Zitat von Patito:

Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde.

Dann liegt der Fehler aber auch bei dir.

Wenn du "referenzählende" Variablen hast, und du denen unterm Arsch weg die Objekte klaust, wovon die natürlich nichts mitbekommen,
dann können die nur davon ausgehen, daß die darin verlinkte Instanz gültig ist und es werden die Referenzen gezählt (bzw. es wird versucht).

- Entweder es wird über die Referenzzählung der Speicher freigegeben
- und wenn nicht, dann darf die Variable nicht referenzzählend sein
- oder du mußt die referenzzählende Variable auf nil setzen (unter böswilliger Umgehung der Referenzzählung), sobald du das Objekt freigibst, oder bevor die Variable freigegeben wird, bzw. bevor sie einen neuen Wert bekommt

- und es darf auch keiner mehr die "ungültige" Referenz daraus verwenden

Zitat von TiGü:

Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:

Der meckert doch?

B ist nicht initialisiert

Zitat von TiGü:

// folgendes funktioniert problemlos, obwohl das Objekt freigeben wurde!

Die Speicherverwaltung ht den speicher aber "oftmals" noch nicht sofort freigegeben.

Das kann man aber zum Debuggen beheben.
- FastMM entsprechend einstellen
- oder einen Debug-Speichermanager verwenden

welche die Objektinstanzen zerstören/überschreiben, womit des beim nächsten Zugriff knallt


PS: Zugrif auf "ungültige" Zeiger .... wie oben erwähnt.
Das Objekt ist weg, aber DU hast den Instanzzeiger in MySomeThingObject nicht bereinigt.

[TiGü]

Zitat von himitsu:

Zitat von TiGü:

Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:

Der meckert doch?

B ist nicht initialisiert

Zitat von himitsu:

PS: Zugrif auf "ungültige" Zeiger .... wie oben erwähnt.
Das Objekt ist weg, aber DU hast den Instanzzeiger in MySomeThingObject nicht bereinigt.

Eben das wollte ich zeigen!
Solange der Pointer nicht ungültig wird, wird ja auch beliebig in die Methoden gesprungen.
Wenn hier fröhlich Interface- und Objektreferenzen gemischt werden (sollt ihr dafür alle in der Hölle schmoren) dann geht auch folgends:

Delphi-Quellcode:

function TMyDoSomething.DoSomeThing : Integer;
begin
  Result := 123;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  MySomeThingObject : TMyDoSomething;
  MagicNumber : Integer;
begin
//  MySomeThingObject := TMyDoSomething.Create;
  MagicNumber := MySomeThingObject.DoSomeThing;
// MagicNumber hat jetzt den Wert 123, obwohl kein Objekt erzeugt wurde! Schwarze Magie? ;-)
end;

Von daher soll der Compiler doch ruhig in die eigenen _AddRef- und _Release-Methoden springen, wenn man meint sowas brauchen zu müssen!

[Whookie]

Ich seh schon ... heißes Thema ...

Da es mir aber um die Implementierung mit Interfaces geht habe ich das ganze nochmals vereinfacht und komplett auf Interfaces umgestellt. Dazu gibts ein eigenes IAdmin-Interface in dem die Sachen definiert sind die vorher eben nur in der Objektinstanz zur Verfügung standen.

Die Implementierung habe ich hier angehängt weil es noch ein Problem bei der Verwaltung der Interfaces gibt und ja, ohne FastMM gibts keine vernünftige Delphi-Entwicklung !

Nochmals zur Erklärung: Die "Hauptliste" (fIntfLst) wird aus einer Textdatei erstellt, es gibt um die 20 verschiedenen Klassen die aus der Kombination von ca. 10 Interfaces bestehen. Diese "Knoten" stehen noch untereinander in Beziehung und daher speichern die Knoten diese Beziehungen in privaten Listen (wie z.B.: TTest.fMyNodes)...

Eigentlich dachte ich ja, das bei reiner Interface-Verwendung keine Probleme mehr auftreten, aber irgendwie schaffe ich es durch meine Querverlinkung die Referenzzählung durcheinander zu bringen (siehe uImpl.pas Zeile 170)...

[TiGü]

Zitat von Whookie:

Eigentlich dachte ich ja, das bei reiner Interface-Verwendung keine Probleme mehr auftreten, aber irgendwie schaffe ich es durch meine Querverlinkung die Referenzzählung durcheinander zu bringen (siehe uImpl.pas Zeile 170)...

Mir ist nicht ganz klar, worauf das Testprogramm abzielt, aber im Anhang findest du eine Version ohne Speicherleck.
Man kann sich die TObjectList<T> und die Item-Klasse komplett sparen, aber ich merke du hast mein Beispiel mit dem Dictionary weiter oben auch nicht wirklich näher ausprobiert und/oder verstanden.

Ansonsten merkt man am Quelltext, dass du häufig viel zu kompliziert denkst und durch die Brust-ins-Auge-Lösungen bevorzugst.

Zitat von OlafSt:

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi

Interfaces werden seit Delphi 4 unterstützt, das sind auch schon ein paar Tage länger.
Hätte man sich auch mal zwischenzeitlich mit beschäftigen können...

[OlafSt]

Zitat von TiGü:

Zitat von Whookie:

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi

Interfaces werden seit Delphi 4 unterstützt, das sind auch schon ein paar Tage länger.
Hätte man sich auch mal zwischenzeitlich mit beschäftigen können...

Wie man an meinem Vorposter sieht, war es doch nicht so verkehrt, sich lieber mit Generics oder anderen wichtigen Neuerungen zu befassen als mit dieser halblebendigen Implementation seine Zeit zu vergeuden In C# oder gar C++ wird mir das hier gelernte aber deutlich weiterhelfen.

[Der schöne Günther]

Weak References gibt es ja schon länger auf dem "Nextgen"-Compiler. Da mich der nicht interessiert, hoffe ich seit langem darauf, dass das endlich mal für den Desktop kommt (http://www.delphipraxis.net/176352-w...-compiler.html)

Gerade auf dem Desktop versucht ja auch Emba immer bis zu Julius Caesar rückwärtskompatibel zu sein. Aber was ist mit neuen Projekten die keine Altlasten mehr unterstützen müssen?

[Whookie]

Zitat von TiGü:

Zitat von Whookie:

Eigentlich dachte ich ja, das bei reiner Interface-Verwendung keine Probleme mehr auftreten, aber irgendwie schaffe ich es durch meine Querverlinkung die Referenzzählung durcheinander zu bringen (siehe uImpl.pas Zeile 170)...

Mir ist nicht ganz klar, worauf das Testprogramm abzielt, aber im Anhang findest du eine Version ohne Speicherleck.
Man kann sich die TObjectList<T> und die Item-Klasse komplett sparen, aber ich merke du hast mein Beispiel mit dem Dictionary weiter oben auch nicht wirklich näher ausprobiert und/oder verstanden.

Ansonsten merkt man am Quelltext, dass du häufig viel zu kompliziert denkst und durch die Brust-ins-Auge-Lösungen bevorzugst.

Habe ich mir angesehen, aber die Welt ist halt nicht immer so einfach wie man es sich gerne machen würde. Die Hauptliste enthält bereits einen Hash und ist danach sortiert (um effizient darauf zugreifen zu können), alle anderen Listen benötigen keinen Namen und keinen Hash sie werden beim Parsen korrekt zusammengestellt und niemals durchsucht.
Das Beispiel ist soweit reduziert, dass nur noch das wesentliche (die gegenseitige Verlinkung) zu sehen ist.

Falls Du Dir die Implementierung von TDictionary mal angesehen hast, ist das ein dynamisches Array aus Records mit HashCode, Key und Value also genau was TListData auch enthält. Wo also die Liste verwaltet wird spielt meines Erachtens nach nur eine untergeordnete Rolle. Der einzige Unterschied liegt eventuell in der etwas lahmen Suche von TDictionary...


Wenn du schon die Zitatfunktion bemühst:

Zitat von TiGü:

Zitat von Whookie:

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi

Interfaces werden seit Delphi 4 unterstützt, das sind auch schon ein paar Tage länger.
Hätte man sich auch mal zwischenzeitlich mit beschäftigen können...

dann versuch das mal so, dass es nicht sinnentstellend wird:

Zitat von OlafSt:

Zitat von TiGü:

Zitat von OlafSt:

Sehe ich das richtig, ...

Wie oben erwähnt,...

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi Ich ...

Aber ich gebe zu, soviele Einrückungen können schon ganz schön verwirrend sein

[TiGü]

Zitat von Whookie:

Habe ich mir angesehen, aber die Welt ist halt nicht immer so einfach wie man es sich gerne machen würde. Die Hauptliste enthält bereits einen Hash und ist danach sortiert (um effizient darauf zugreifen zu können), alle anderen Listen benötigen keinen Namen und keinen Hash sie werden beim Parsen korrekt zusammengestellt und niemals durchsucht.
Das Beispiel ist soweit reduziert, dass nur noch das wesentliche (die gegenseitige Verlinkung) zu sehen ist.

Falls Du Dir die Implementierung von TDictionary mal angesehen hast, ist das ein dynamisches Array aus Records mit HashCode, Key und Value also genau was TListData auch enthält. Wo also die Liste verwaltet wird spielt meines Erachtens nach nur eine untergeordnete Rolle. Der einzige Unterschied liegt eventuell in der etwas lahmen Suche von TDictionary...

So weit, so richtig, aber warum das Rad zweimal erfinden?
Sind denn diese anderen Listen von einen anderen (eigenen) Listentyp ohne Hash?

Und der entscheidene Unterschied ist: Ich habe keine Speicherlecks beim Beenden (laut FastMM).
Um wieviel langsamer ist denn die Suche von TDictionary im Verhältnis zu deiner Lösung?

Zitat von Whookie:

Wenn du schon die Zitatfunktion bemühst:

Da habe ich mich vertan! Sorry, ist korrigiert!

[Whookie]

Zitat von TiGü:

...aber warum das Rad zweimal erfinden?

Code:

fList: TObjectList<TListData>

erfindet ja das Rad nicht neu...

Zitat von TiGü:

Sind denn diese anderen Listen von einen anderen (eigenen) Listentyp ohne Hash?

Es ist eine einfache Liste (in der Interfacelosen-Variante vom Type TObjectList) ohne weitere Daten (der Besitzer durchläuft sie, um z.B. allen Elementen eine Nachricht zu übermitteln).

Zitat von TiGü:

Und der entscheidene Unterschied ist: Ich habe keine Speicherlecks beim Beenden (laut FastMM).

Die habe ich auch nicht, solange es keine Quer-Referenzen gibt. Sobald aber eines der Objekte eine zusätzliche Liste pflegt (siehe Beitrag #39, uImpl.pas, Zeile 130), beginnt der Spaß mit der Referenzzählung. Ich nehme an, dass sich das - unabhängig von der verwendeten Liste - nur durch Manipulation der Referenzzählung (Beitrag 45, himitsu), wirklich lösen lässt.

Zitat von TiGü:

Um wieviel langsamer ist denn die Suche von TDictionary im Verhältnis zu deiner Lösung?

Meine braucht im worst case log2(n) die von Delphi im Durchschnitt n/2, das sind bei 100000 Elementen 17 zu 50000 Vergleiche...


Edit: Was deine Version in #51 angeht, die hat zwar kein Speicherleck, funktioniert aber andererseits auch nicht richtig (du erzeugst zwar 4 Elemente die alle IInteger unterstützen, aber bei der Ausgabe sind es nur mehr 3....)

[himitsu]

Wenn der Speichermanager aufräumt, dann wird es auch knallen. Oder wenn inzwischen etwas Anderes an der Stelle steht, dann produziert man damit einen Buffer-Overrun,
wenn man auf ungültige Variablen zugreift.

Und das ist nicht erst seit Interfaces so.

Delphi-Quellcode:

var
  o: TMyIrgendwas;

o := TMyIrgendwas.Create;
o.Free;
o.DoWas;  // Fehler

o := TMyIrgendwas.Create;
FreeAndNil(o);
o.DoWas;  // Zugriffsverletzung bei Addresse 0

Man kann gern die Speicherverwaltung komplett der Referenzzählung des Interfaces überlassen.

Und wenn es unbedingt sein muß, dann holt man sich "kurzzeitig" nochmal eine Objekt-Referenz aus dem Interface raus (an dieser Stelle muß parallel eine Interface-Referenz vorhanden sein), denn Delphi bietet seit einer Weile ein Pseudo-Interface an, welches die Objektreferenz zurückgibt. (wenn im Interface ein Delphi-Objekt steckt)
Und an diese Objektreferenz kommt man z.B. via intf AS TObject ran.
Man kann natürlich auch eigene Getter in seinem Interface verbauen, welches Objekt-Instanzen zurückgibt.
Sobald dann die "paralelle" Interface-Referenz freigegeben wird, ist die Objektreferenz als "ungültig" anzusehen.