Hallo,
im Beitrag
Pointer existiert, das Objekt dahinter nicht. Wie zuverlässig prüfen? hatte ich etwas eingeworfen was dann etliche lange Antworten gegeben haben, die allerdings nicht zu dem Thema gehörten. Daher nochmals ein neuer Beitrag.
An das Problem mit Mischung von Objekt- und Interface-Referenz hatte ich zuerst gedacht. Das war es aber nciht.
Die Ursache für mein Problem ist mit inzwischen bekannt und hat mehrere Ursachen. Hier ein Beispiel - extremst vereinfacht:
Delphi-Quellcode:
TBlub = class (TInterfacedObject, IBlub1, IBlub2);
//Irgend wo steht dann
var blub : IBlub1;
begin
blub := TBlub.Create() as IBlub1;
...
end;
//weiter:
procedure TBlub.Initialize(); //override
var blbl: IBlub2;
begin
blb := Self as IBlub2; //Hier erhöht sich der Referenzzähler
Self.Egal := irgeeinservice.CreateEtwas(blbl);
blbl := Nil; //Hier erniedrigt sich der Referenzzähler
end;
procedure TBlub.AfterConstruction();//override
begin
// Call AfterConstruction of base class
inherited; //Da drin geht der Referenzzähler auf 0
// Initialize member of descendant class
self.Initialize();
//...
end;
Soweit der hoffentlich sinnvolle Auszug.
Ich finde es an sich ja schon logisch, dass man in AfterConstruction zuerst inherited aufruft und dann erst das eigene macht.
1. Problem (meinte der Kollege): Warum macht man so viel Dinge im Konstruktor. Der sollte schlank bleiben.
2. Ein Hack in der
RTL den ich für nicht so dolle finde:
Delphi-Quellcode:
procedure TInterfacedObject.AfterConstruction;
begin
// Release the constructor's implicit refcount
AtomicDecrement(FRefCount);
end;
// Set an implicit refcount so that refcounting during construction won't destroy the object.
class function TInterfacedObject.NewInstance: TObject;
begin
Result := inherited NewInstance;
TInterfacedObject(Result).FRefCount := 1;
end;
Mein Problem habe ich nun gelöst, indem ich das mein Ding nicht mehr im Konstruktor mache sondern später erst.
Aber: Wie hat sich der Erfinder das gedacht?