Kann ich das IntfClear vorziehen?

[Der schöne Günther]

Disclaimer: uses Xml.XmlIntf, Xml.XmlDoc, Winapi.ActiveX
Folgender Quellcode verursacht eine Zugriffsverletzung:

Delphi-Quellcode:

procedure myProc();
begin
   CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
   try
      NewXMLDocument();
   finally
      CoUninitialize()
   end;
end;

Warum? Weil das "anonym" erzeugte XML-Dokument nicht nach dem CoUninitialize() freigegeben werden darf. Das geschieht aber weil der Compiler (für uns unsichtbar) nach dem "end;" der Methode noch Code einfügt um ein _Release auf dem anonymen IXMLDocument aufzurufen.

Was tun wir also? Wir nehmen uns eine Variable und geben es manuell frei:

Delphi-Quellcode:

procedure myProc2();
var
   xmlDoc: IXMLDocument;
begin
   CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
   try
      xmlDoc := NewXMLDocument();
      xmlDoc := nil;
   finally
      CoUninitialize()
   end;
end;

Eigentlich könnten wir jetzt Feierabend machen. Doch wenn es sich so einfach lösen ließe, müsste folgendes ja auch gehen, oder?

Delphi-Quellcode:

procedure myProc3();
var
   xmlDoc:      IXMLDocument;
   xmlNode:   IXMLNode;
begin
   CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
   try
      xmlDoc := LoadXMLData('<rootNode />');
      xmlNode := xmlDoc.DocumentElement.AddChild('someChildNode');
      xmlDoc := nil; xmlNode := nil;
   finally
      CoUninitialize()
   end;
end;

Leider haben wir hier unsere alte AV wieder zurück. Komisch, wir haben doch das IXMLDocument und die IXMLNode freigegeben. Leider nicht, denn anonym haben wir uns mit .DocumentElement wieder eine anonyme IXMLNode eingehandelt.

Man könnte nun entweder die Sache mit wachsamen Augen und einem Sack voller unnötiger Variablen bekämpfen oder man macht es folgenderweise:

Delphi-Quellcode:

procedure doXmlStuff();
var
   xmlDoc: IXMLDocument;
begin
   xmlDoc := LoadXMLData('<rootNode />');
   xmlDoc.DocumentElement.AddChild('someChildNode');
   xmlDoc := nil;
end;

procedure myProc();
begin
   CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
   try
      doXMLStuff();
   finally
      CoUninitialize()
   end;
end;

Daher meine Frage: Kann ich das vermeiden? Kann ich das IntfClear am Ende einer Methode vorziehen? Dann bräuchte ich die Extramethode nicht.


Dies war ein kostenloser Probeartikel aus der Reihe Probleme welche die Welt bewegen.

[himitsu]

Zitat von Der schöne Günther:

Kann ich das IntfClear am Ende einer Methode vorziehen?

Nein.

Internen Temp-Variablen kannst du nicht freigeben, da du nicht an deren Variablen ran kommst.
Einzige Lösungen:

• vermeiden solcher Variablen, also alle Rückgabewerte immer in Variablen ... das gilt auch für Zwischenschritte, wo soein Interface entstehen könnte.
  In deinem Fall wäre es das Result vom xmlDoc.DocumentElement im xmlDoc.DocumentElement.AddChild('someChildNode');
• den Code in einen extra Bereich verschieben, bei dessen Ende alles aus dessen Scope freigegeben wird
• nichts in initialization/finalization, was ein Interface/DynArray/String/Vatiant/... zurück gibt

Keine Aufrufketten (maximal 1 Punkt pro Ausdruck, abgesehn von Namespaces) und alle Results selbst behandeln.

Delphi-Quellcode:

CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
try
  xmlDoc := LoadXMLData('<rootNode />');
  xmlRoot := xmlDoc.DocumentElement;
  xmlNode := xmlRoot.AddChild('someChildNode');
  xmlNode := nil;  xmlRoot := nil;  xmlDoc := nil; 
finally
  CoUninitialize;
end;

Delphi-Quellcode:

{procedure doXmlStuff;
var
  xmlDoc: IXMLDocument;
begin
  xmlDoc := LoadXMLData('<rootNode />');
  xmlDoc.DocumentElement.AddChild('someChildNode');
  //xmlDoc := nil;
end;}

procedure doXmlStuff;
begin
  LoadXMLData('<rootNode />').DocumentElement.AddChild('someChildNode');
end;  // hier alles automatisch weg

procedure myProc;
begin
  CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
  try
    doXMLStuff;
  finally
    CoUninitialize;
  end;
end;

[TiGü]

Warum machst du das eigentlich so?
Rufst du die procedure doXmlStuff() im Main-Thread auf oder in einen eigenen Thread?

Für MainThread:

Projektdatei ->

Delphi-Quellcode:

begin
  System.Win.ComObj.CoInitFlags := COINIT_APARTMENTTHREADED;
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TKrims, Krams);
  Application.Run;
end.

In einen eigenen Thread würde ich die Co...-Funktionen im jeweiligen Create und Destroy rufen.

[Der schöne Günther]

Hm, ich kannte es nur so.
So mache ich das immer in Konsolenanwendungen oder Neben-Threads. Das System.Win.ComObj sehe ich grade zum ersten mal. Man entdeckt immer wieder neues

Zitat von TiGü:

In einen eigenen Thread würde ich die Co...-Funktionen im jeweiligen Create und Destroy rufen.

Und wie in Indy-Eventhandlern bei denen ich nicht weiß, in welchem Thread sie grade ausgeführt werden?
(Wenn wir abschweifen bitte ich um Vergebung und den Hinweis darauf)

[sahimba]

Zitat von himitsu:

Keine Aufrufketten (maximal 1 Punkt pro Ausdruck, abgesehn von Namespaces

Ich muss grinsen. Nicht wegen Deiner Aussage. Aber mehr und mehr Libs werden mit dem schönen Bullshitbingobuzzword "Fluent Interfaces" vermarktet und wie toll und schön und ach-so-elegant der Code doch dann ist. Und dann kommt die Ernüchterung. Ach ja.