Umgang mit Interfaces

[JamesTKirk]

Zitat:

Zitat von TiGü (Beitrag 1239683)

Zitat:

Zitat von Patito (Beitrag 1239679)

Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde.
Die zur Zeit einzig sinnvolle Lösung für das Problem nennt sich Free-Pascal...

Dann lass es doch weiterhin lustig aufrufen.
Solange du in den selbstimplementierten _AddRef und _Release Methoden kein Schindluder betreibst geht das doch?!?
Wo ist das Problem?
Oder verhält sich das in Free-Pascal anderes?

Mit COM Interfaces verhält sich FPC genauso wie Delphi, nur dass das Interface eventuell an anderen Orten als bei Delphi freigegeben wird. Auf was Patito anspielte sind CORBA bzw. Raw Interfaces, die wie COM Interfaces aussehen, aber nicht von IInterface erben und damit auch keine automatische Referenzzählung haben.

Gruß,
Sven

[OlafSt]

Zitat:

Zitat von TiGü (Beitrag 1239564)

Zitat:

Zitat von OlafSt (Beitrag 1239546)

Sehe ich das richtig, das mein

Delphi-Quellcode:

MySomeThingObject

bei Verlassen der Prozedur automatisch freigegeben wird, obwohl ich zuvor mit

Delphi-Quellcode:

TMyDoSomething.Create;

Speicher dafür alloziert habe ?

Wie oben erwähnt, ja!

Mit einem normalen Objekt hättest du ein Speicherleck!

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi ;) Ich hätte nicht gedacht, das meine simple Frage eine derartige Diskussion auslöst, die für mich aber ungeheuer interessant war. Bleibt noch eine letzte Frage übrig. Wenn ich so ein selbsterzeugtes MySomeThingObject nun in eine TList (nicht in der Prozedur deklariert) stecke, dann:

A) bleibt mein MySomeThingObject trotz verlassen der Prozedur existent
B) mit dem Freigeben meiner TList werden auch alle dort drin befindlichen MySomeThingObjects elimiert ?

Wenn hier 2x JA kommt, haben wir ja schon fast C#-Verhältnisse...

[himitsu]

bei Objekten:
Nein
und
Nein

Objekte mit TObjectList:
Nein
Ja

Interface mit Interfaces ode TObjectlist:
Ja
Ja

[Whookie]

Aber einsetzbar sind Interfaces anscheinend nur für simple Dinge, sobald Beziehung zwischen den Instanzen abgebildet werden müssen, verhindert die Referenzzähling eine Verwendung (siehe Beispiel aus meinem letzen Beitrag, dort werden Destructoren nicht aufgerufen, weil die Referenzzählung es beim Freigeben verhindert).

Ich habe das selbe Beispiel nochmals mit Interfaces ohne Referenzzählung implementiert, dann funktiniert die Referenzierung zwar, aber beim Freigeben kommet es dann zu Zugriffsfehlern weil Delphi anscheinend _Release auch dann noch aufruft, wenn das dazugehörige Objekt nicht mehr existiert.

Bleibt als die Schlußfolgerung, das Interfaces nicht geeignet sind komplexere Zusammenhänge abzubilden?!??

Für meinen speziellen Fall wäre es also eine Option eine Basisklasse zu deklarieren, die alle Eigenschaften aller Interfaces beinhaltet und in den jeweilig abgeleiteten Kindern die benötigte Funktion entsprechend zu implementieren. Dann lassen sich die Referenzen untereinander verlinken, aber schön ist das halt nicht!

[himitsu]

Man muß dann nur die Referenzzählung richtig implementieren.

z.B.
- von den Unterkomponenten die Referenzzählung auf den obersten Knoten weiterleiten (bzs, an den Besitzer)
- Rückwärtsreferenzen aus der Referenzzählung ausnehmen

[Whookie]

Zitat:

Zitat von himitsu (Beitrag 1239861)

- von den Unterkomponenten die Referenzzählung auf den obersten Knoten weiterleiten (bzs, an den Besitzer)
- Rückwärtsreferenzen aus der Referenzzählung ausnehmen

..wenn ich mir das so recht überlege muss die Not schon groß sein, so etwas anzugehen (schon gar bei den nur rudimentär vorhandenen Debugmöglichkeiten von XE4 :evil:)...

[jaenicke]

Ich habe das bei mir so, dass sich die GUI-Interfaces gegenseitig mit den dahinterliegenden Interfaces einklinken. Wenn man das sauber umsetzt und klar ist wer sich wann und wie wieder deregistriert, hatte ich damit noch nicht die kleinsten Probleme.

Und der Debugger funktioniert bei mir problemlos, außer wenn wieder jemand with benutzt hat. (Das geht dann eh gleich an den Pranger...)

[Whookie]

Zitat:

Zitat von jaenicke (Beitrag 1239878)

Und der Debugger funktioniert bei mir problemlos, außer wenn wieder jemand with benutzt hat. (Das geht dann eh gleich an den Pranger...)

Dann verurteile ich Dich mal zu 30 Tagen XE4-Debugging... da geht auch alles problemlos ... ;) ... solange man nicht sowas komplexes wie ein Array oder eine Liste verwendet

[jaenicke]

Zitat:

Zitat von Whookie (Beitrag 1239900)

Dann verurteile ich Dich mal zu 30 Tagen XE4-Debugging... da geht auch alles problemlos ... ;) ... solange man nicht sowas komplexes wie ein Array oder eine Liste verwendet

Wir haben XE4 seit dem Erscheinen bis zum Update 1 von XE5 genutzt. Bei mir gibt es mit Array oder Listen kein Problem. Grad nochmal ausprobiert.

[Whookie]

Zitat:

Zitat von jaenicke (Beitrag 1239905)

Wir haben XE4 seit dem Erscheinen bis zum Update 1 von XE5 genutzt. Bei mir gibt es mit Array oder Listen kein Problem. Grad nochmal ausprobiert.

Dann versuch mal das komplexe Beispiel: http://www.delphipraxis.net/175322-x...ml#post1218435


Ach ja, und weil dein XE4 ja so toll geht probier mal das:

Code:

unit uTest;

interface

Const
  maxXData = 4;
  maxYData = 4;

Type
  TData = Array[0..maxXData+1, 0..maxYData+1] Of Char;

Procedure TestIt;

implementation

Const
  CX: Array[0..7] Of Integer = (-1,  0,  1,  1,  1,  0, -1, -1);
  CY: Array[0..7] Of Integer = (-1, -1, -1,  0,  1,  1,  1,  0);

Var
  AData: TData;


function FindWord( AString: String): Boolean;
var
  iX: Integer;
  iY: Integer;

  function WordAt(AIdx, x,y, ox,oy: Integer): Boolean;
  var
    i: Integer;
  begin
    Result := False;

    if AString[AIdx] = AData[x,y] then
    begin
      Inc(AIdx);
      if AIdx > Length(AString) then
      begin
        Result := TRUE;
      end
      else
      begin
        for i := 0 to 7 do
        begin
          if Not (((x+CX[i])=ox) And ((y+CY[i])=oy)) then  //<--------- Breakpoint
          begin
            Result := WordAt(AIdx, x+CX[i], y+CY[i], x, y);
            if Result then
              Break;
          end;
        end;
        i := 0;
      end;
    end
    else
    begin
      i := 0;
    end;
  end;

begin
  Result := FALSE;
  for iX := 0 to maxXData-1 do
  begin
    for iY := 0 to maxYData-1 do
    begin
      if WordAt(1, iX+1, iY+1, 0, 0) then
      begin
        //Mark AString as found
      end;
    end;
  end;
end;


Procedure TestIt;
var
  iX: Integer;
  iY: Integer;
begin
  for iX := 0 to maxXData-1 do
  begin
    for iY := 0 to maxYData-1 do
    begin
      AData[iX, iY] := Char(Ord('A')+Random(Ord('Z')-Ord('A')+1));
    end;
  end;
  AData[3,3] := 'T';
  //
  FindWord('TEST');
end;
end.

Mach einen Breakpoint an der markierten Stelle und füge folgendes in die Liste der Überwachten Ausdrücke ein:

AData[x,y]
AString[AIdx]
(x+CX[i])
(y+CY[i])

Dann kriegst du nämlich 4 mal "Nicht verfügbarer Wert" ... soviel zu "..Bei mir gibt es mit Array oder Listen kein Problem..."

[TiGü]

Zitat:

Zitat von Whookie (Beitrag 1239693)

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:

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...:wink:

[Patito]

Zitat:

Zitat von Whookie (Beitrag 1239859)

Aber einsetzbar sind Interfaces anscheinend nur für simple Dinge, sobald Beziehung zwischen den Instanzen abgebildet werden müssen, verhindert die Referenzzähling eine Verwendung (siehe Beispiel aus meinem letzen Beitrag, dort werden Destructoren nicht aufgerufen, weil die Referenzzählung es beim Freigeben verhindert).

Bleibt als die Schlußfolgerung, das Interfaces nicht geeignet sind komplexere Zusammenhänge abzubilden?!??

Richtig erkannt. Man stößt bei dem Thema etwas an die Grenzen von Delphi. Als Interfaces in Delphi eingeführt wurden, ist denen leider gerade der Chef-Entwickler abhanden gekommen...
Systeme mit automatischer Referenzzählung kennen normalerweise so etwas wie Weak-References. Die gibt es bei Delphi-Interfaces so nicht. Alles ist eine Strong-Referenz, und mit einer solchen Einschränkung zu programmieren ist ein ziemlicher Krampf. (Grüße an die ARC-Fans, die das noch nicht ganz mitbekommen haben...)

In Delphi kann man die Probleme zwar umgehen, aber es ist nicht ganz einfach. Ich habe vor ein paar Jahren mal versucht einer Moderatorin vom Borland-Forum zu erklären wie sie ihre Interface-Probleme umgehen kann, aber letztenendes hat sie ihre Delphi-Frameworks dann aufgegeben und sich einer anderen Programmiersprache zugewendet.

Etwas, das man häufig brauchen kann, ist z.B. ein Benachrichtigungs-Mechanismus, mit dem man einem Objekt, das eine Interface-Referenz hält mitteilen kann, dass es seine Referenz jetzt löschen muss (geht per Observer-Pattern). Hat man dann die Referenzen, die man selbst im Code verteilt hat erst einmal im Griff, muss man auch noch auf die Referenzen aufpassen, die der Compiler für Zwischenergebnisse (Funktions-Rückgabewert, ...) irgendwo auf den Stack gepackt hat. Macht alles keinen Spass.

Zur Lösung des Problems, wie gesagt: Ich habs für mich in Delphi gelöst, andere haben einfach aufgegeben. Die lautstärkste Delphi-Fraktion behauptet steif und fest, dass man Weak-References sowieso niemals braucht. An Deiner Stelle würde ich in Delphi die Verwendung von Interfaces zurückfahren oder auf Free Pascal umsteigen. Dort gibt es diese ganzen künstlichen Probleme nicht...

[jaenicke]

Zitat:

Zitat von Whookie (Beitrag 1239909)

Dann versuch mal das komplexe Beispiel: http://www.delphipraxis.net/175322-x...ml#post1218435

Das Entscheidende steht in dem QC Eintrag... mit Bereichsüberprüfung. Die habe ich nie an außer zu speziellen Debugzwecken oder für Unittests etc., das macht das Programm ansonsten nur unnötig langsam.

[himitsu]

Zitat:

Zitat von Patito (Beitrag 1239935)

Systeme mit automatischer Referenzzählung kennen normalerweise so etwas wie Weak-References. Die gibt es bei Delphi-Interfaces so nicht.

Das liegt nicht daran, daß es vergessen wurde.

In Delphi gibt es keine Stelle wo die Position aller Variablen registriert sind.
Auch gibt es keine Möglichkeiten nach Variablen zu suchen.

Systeme wie .Net oder JavaScript verwalten den Speicher anders, haben da praktisch eine Liste aller Variablen und können, wenn ein Interface freigegeben wird, einfach die restlichen Variablen suchen und diese auf Nil setzen.

In Delphi geht das nur, wenn man sowas auch für Variablen einbaut, also wo sich Variablen an einer globalen Stelle oder direkt beim Interface registrieren.
(das wollte ich mal vor Jahren nachrüsten, aber den nötigen Änderungswunsch hat man bisher seit knapp 6 Jahren igoriert, bzw. seit fast 4 Jahren den etwas neueren QC-Report).
http://qc.embarcadero.com/wc/qcmain.aspx?d=82524



Also seit 3 Jahren hätten wie Weak-Referenzen haben können, aber wer nicht will, der will halt nicht.
Selbst wenn man das jetzt nicht direkt als Klassen-Operatoren einbaut, sondern erstmal die nur 3 Grundevents implementiert hätte,
was mit knapp 10 Zeilen Quellcode erledigt gewesen wäre, wäre das Problem schon länger lösbar. (auch wenn nicht ganz so schön)

[OlafSt]

Zitat:

Zitat von TiGü (Beitrag 1239921)

Zitat:

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...:wink:

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 :wink: 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:

Zitat von jaenicke (Beitrag 1239936)

Das Entscheidende steht in dem QC Eintrag... mit Bereichsüberprüfung. Die habe ich nie an außer zu speziellen Debugzwecken oder für Unittests etc., das macht das Programm ansonsten nur unnötig langsam.

Die Bereichsüberprüfung (zusammen mit der I/O Prüfung und der Überlaufprüfung) ist absolute Pflicht, wir hatten schon Leute in der Firma, die uns durch abschalten Stress ohne Ende bereitet haben...
Performanz mag ja hin und wieder ein Faktor sein, Sicherheit geht aber vor!

[himitsu]

Aus diesem Grund hatte ich mir schon vor vielen Jahren mal gewünscht, daß diese Optionen standardmäßig in den Projektoptionen "erstmal" aktiviert sind (vorallem im Debug-Build).
Denn grade die Bereichsprüfungen würden viele Probleme lösen ... sehr viele Fragen hier (vorallem von Anfängern) sind auf Probleme mit falschen Indize zurückzuführen,
welche selbst gefunden worden wäre, wäre diese Option aktiv gewesen.

Und man sich das dann eben selber deaktivieren muß, wenn es unbedingt sein muß.
Aber seit den neuen Projektoptionen im Delphi, die scheinbar keine Vorgaben mehr ermöglichen, hab ich aufgegeben darauf zu hoffen. (oder warum sind immernoch die Debug-DCUs standardmäßig aktiv?)

[Whookie]

Zitat:

Zitat von TiGü (Beitrag 1239921)

Zitat:

Zitat von Whookie (Beitrag 1239693)

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


:idea: Wenn du schon die Zitatfunktion bemühst:

Zitat:

Zitat von TiGü (Beitrag 1239921)

Zitat:

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...:wink:

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

Zitat:

Zitat von OlafSt (Beitrag 1239805)

Zitat:

Zitat von TiGü (Beitrag 1239564)

Zitat:

Zitat von OlafSt (Beitrag 1239546)

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 :shock:

[TiGü]

Zitat:

Zitat von Whookie (Beitrag 1239948)

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:

Zitat von Whookie (Beitrag 1239948)

:idea: Wenn du schon die Zitatfunktion bemühst:

Da habe ich mich vertan! Sorry, ist korrigiert!

[jaenicke]

Zitat:

Zitat von Whookie (Beitrag 1239943)

Die Bereichsüberprüfung (zusammen mit der I/O Prüfung und der Überlaufprüfung) ist absolute Pflicht, wir hatten schon Leute in der Firma, die uns durch abschalten Stress ohne Ende bereitet haben...
Performanz mag ja hin und wieder ein Faktor sein, Sicherheit geht aber vor!

Bei uns gab es in den letzten Jahren in der Hinsicht keinerlei Probleme. Auch in Tests mit aktivierter Prüfung gab es keine entsprechenden Fehler. Die Performance ist ohne die Option jedoch spür- und messbar besser. Deshalb macht es in unserem Fall keinen Sinn die Option zu aktivieren.

Wenn natürlich solche Fehler auch tatsächlich vorkommen, ist das etwas anderes. Da müsste man sich aber schon fragen woran das liegt und ob sich das vermeiden lässt.

[stahli]

Es schweift etwas vom Thema ab aber ich schließe mich da Himi an.
Die Grundeinstellungen sollten für Anfänger optimiert sein.
Wer dann weiß was er tut kann die Bereichsprüfung ausschalten und die Performance erhöhen.

[Whookie]

Zitat:

Zitat von TiGü (Beitrag 1239954)

...aber warum das Rad zweimal erfinden?

Code:

fList: TObjectList<TListData>

erfindet ja das Rad nicht neu...

Zitat:

Zitat von TiGü (Beitrag 1239954)

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:

Zitat von TiGü (Beitrag 1239954)

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:

Zitat von TiGü (Beitrag 1239954)

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

[Whookie]

Zitat:

Zitat von jaenicke (Beitrag 1239956)

Wenn natürlich solche Fehler auch tatsächlich vorkommen, ist das etwas anderes. Da müsste man sich aber schon fragen woran das liegt und ob sich das vermeiden lässt.

Es gibt leider Menschen mit den unterschiedlichsten Charakterzügen...

Zitat:

Zitat von stahli (Beitrag 1239960)

...Die Grundeinstellungen sollten für Anfänger optimiert sein.
Wer dann weiß was er tut kann die Bereichsprüfung ausschalten und die Performance erhöhen.

:thumb:


...wobei, das erst die QM-Abteilung nach ausgiebigen Tests erlauben sollten.