lrlr hat geschrieben:java ist meiner meinung nach die "schönste" objektorientierte sprache, da wird sehr viel mit interfaces gearbeitet (u.U funktionierts dort besser , zwecks GC, wober der natürlich auch nachteile hat..)
Ja. Dort läufts ohne Ref-Counting... Wobei GCs wirklich auch ziemlich problematisch sein können. Ernsthaft - für anspruchsvolle Programme braucht man gelegentlich deterministische Speicherverwaltung. Wenn man sich mal den Horror angetan hat zu schauen wie man sowas mit .NET hinbekommt vergeht einem echt die Lust auf GCs.
Die Borländer haben sich ja mit sowas ein schönes Eigentor geschossen. "Wir verwenden jetzt .NET für unsere IDE - Speicherverwaltung läuft jetzt automatisch" und dann hats geleakt bis zur Unbenutzbarkeit...
>Bevor man ein Objekt freigibt muß man ALLE Interface-Referenzen auf das Objekt aus dem Speicher entfernen, sonst knallts irgendwann.
nochmal: du gibts ein object frei, und hast noch referenzen (interfaces) darauf, im extremfall sogar in einem plugin/dpl/wasauchimmer, was du u.U. garnicht mal kennst..
oder einfach in code der nicht von dir ist..
sobald auf das interface zurückgegriffen wird, kracht es..
Nicht ablenken. Das hast Du auch mit Objekten. Und niemand wird bei denen von Dir verlangen immer alle Referenzen aufzuräumen. (Vergleiche das Beispiel von vorher: Eine ObjektListe mit Baumknoten kann man freigeben ohne, dass man erst langwierig die Knoten untersuchen muss und alle Referenzen zwischen den Knoten in der richtigen Reihenfolge entfernen muss).
Wenns ganz sauber sein soll kann man für die Entfernung von Referenzen das Observer-Pattern verwenden und eine Nachricht broadcasten, die allen Abonenten des Interfaces/Objekts mitteilt, dass sie ihre Referenz jetzt entfernen müssen. Das hat aber nichts mit Interfaces an sich zu tun, sondern gilt genauso für Objekt-Referenzen.
anders herum, wenn es nur interfaces gibt, und keine referenzen direkt aufs object, kann dir "nix passieren"
gegenseitig referenzieren geht natürlich schlecht..
Mit der Einstellung wirst Du leaken bis der Arzt kommt... "Nix passieren" ist falsch - eher "Wenns ein Problem gibt sieht man keine vernünftige Fehlermeldung". Im besten Fall leakt man - im schlechteren Fall benutzt jemand das durch die Referenz künstlich am Leben gehaltene Objekt - obwohl es eigentlich schon längst Tod sein sollte.
Stell dir vor das Objekt ist eine Bestellung von 10 Tonnen nassem Beton, die in deinen Vorgarten geliefert werden - willst Du das Objekt freigeben - und riskieren, dass es crasht wenn jemand auf "Versenden" klickt. Oder reicht es Dir deine Referenz zu entsorgen und hoffst dann darauf, dass niemand anderes im Programm eine Referenz hat.
(Destruktoren deterministisch aufrufen können hat einen Sinn!)
das problem hat aber auch m$ und excel usw.
da kann man auch mit active x ein excel interface erhalten, dann ein worksheet, dann excel auf Null setzen, danach hast auch ein nicht funktionierendes worksheet interface...
Genau. Ref-Counting funktioniert nicht mal vernünftig bei den Sachen für die es desigt wurde. Das doofe bei z.B. Word ist auch noch, dass selbst wenn man das Worksheet/Region oder was auch immer später nullt der ursprüngliche Word-Prozess dann immer noch herumhängt bis ihn jemand von Hand abschießt... (die Region-Referenz verhindert die Beendigung des Prozesses, Region-Referenz nullen führt nicht dazu, dass der Prozess beendet wird...)
wenn man activex server schreibt, braucht man es einfach...
dass sie "programmintern" in code üder den man selber "die kontrolle" hat, mehr schaden als helfen, wird sicher stimmen..
aber du kannst nich sagen TInterfacedObject ist "müll", es ist einfach ein notwendiges übel,
wenn man es verwendet, muss man halt wissen was man macht..
Gut an jedem 32.Mai braucht man mal was für COM. Für Interfaces innerhalb einer Programmiersprache ist es aber Müll. Und die COM-geschichten könnte man sicher auch anders lösen... Statt über die RefCounting zu gehen könnte man in Object-Pascal aus auch die Methodenaufruf _AddRef, _Release selbst aufrufen.
Ich bleibe dabei. Das Ding ist Müll. Und ich vermute ernsthaft, dass derjenige, der das designt hat, nicht mehr alle Tassen im Schrank hat..
Verein
Links
Suche