Zugriffsverletzung mit Interfaces und TList-Nachfahre

[FAlter]

Hi,

Codeausschnitt:

Delphi-Quellcode:

  SimpleBrain := TSimpleBrain.Create(1, 1);
  try
    try
      //kleiner Hack zum Testen --> Programmierung dass
      with TNeuron(SimpleBrain.Input[0]) do
      begin
        Output.Add(SimpleBrain.Output[0]);

in der letzten geposteten Zeile kommt es zur AV, wobei nicht einmal die Add-Methode betreten wird, das heißt vermutlich knallt es schon vorher beim Zugriff auf Input[0].Output, weil Input nicht mehr existiert.

SimpleBrain.Input/Output sind Eigenschaften vom Typ TNeuronList, diese gibt ein INeuron-Interface zurück. Ich weiß aber (da es mein Code ist), dass dahinter die Klasse TNeuron steckt, und auf eine Eigenschaft von dieser, die wiederum eine TNeuronList ist, möchte ich (testweise) zugreifen.

Im Debugger wird bei F7 drücken nie durch den Destruktor von TNeuron gegangen, das hatte ich anfangs, da ich durch die Typecasts die Referenzzählöungs-CompilerMagic ausgehebelt habe, aber nun habe ich manuell _AddRef und _Release aufgerufen, und ich lande auch nicht mehr im Destruktor. Mein Neuron sollte also noch existieren.

Nun ja, ich finde die Ursache nicht.

Im Anhang das komplette Programm.

Mfg
FAlter

[Apollonius]

Im Gegensatz zu Klassen im Falle der Einfachvererbung verschiebt sich bei Interface-Casts der Wert deines Zeigers, d.h. Inst as IInterface <> Inst. Deshalb gibt es keine einfache Möglichkeit, vom Interface zurück auf die Objekt-Instanz zu kommen. Wenn du es unbedingt haben willst: klick Allerdings stellt sich dann die Frage, ob du nicht lieber im Interface alles veröffentlichen solltest, was auch in TNeuron ist. Außerdem solltest du dir überlegen, eine TInterfaceList zu verwenden, damit du die Referenzzählung nicht von Hand austricksen musst.

[FAlter]

Hi,

dass sich die Adressen verschieben wusste ich nicht, aber wenn das so ist, gibt es eine logische Erklärung dazu.

Die TInterfacedList kannte ich noch gar nicht... werds auf die umstellen.

Das Problem mit dem im Interface veröffentlichen ist dass dann die Interface-Unit die Listen-Unit im interface-Abschnitt kennen müsste, und umgekehrt sowieso, und das geht leider nicht. Aber ich könnte notfalls TInterfacedList zurückgeben und diese auf meine Klasse Casten, dann habe ich ja wieder Klasse-->Klasse gecastet. Quatsch, dann kom ich ja wieder nur auf ein Interface. Muss wohl ne _GetObject implementieren wi sich das Objekt dann selbst zurückliefert.

Warum gibt der Compiler keine Warnung beim Cast Interface-->Klasse?

Mfg
FAlter

[Apollonius]

Weil du mit dem harten Cast sagst, dass du weißt, was du tust. Wenn du stattdessen versucht hättest, einen as-Cast durchzuführen, hättest du den Fehler "Operand not applicable to this operand type" erhalten.

[FAlter]

Hi,

ich glaubte ja auch zu wissen was ich tue. Es sollte ja eh nur ein Test sein, denn mein SimpleBrain kann ja noch nicht lernen, und ich wollte trotzdem schonmal testen ob die Neuronen arbeiten.
Das Java, mit dem ich derzeit beruflich arbeite, schmeißt bei (blubb)wuppdi auch immer Warnungen raus... idt aber auch kein schickes Delphi.

Naja, Hauptsache ich kann jetzt weitertesten, auch wenn es nicht an die Intelligenz eines Regenwurms heranreichen wird... Vielleicht krieg ich es ja wirklich hin was lernendes zu programmieren.

Mfg
FAlter

[Bernhard Geyer]

Zitat von FAlter:

... , schmeißt bei (blubb)wuppdi auch immer Warnungen raus...

AFAIK ist bei Java (wie unter .NET) eh kein harter Cast möglich. Das obige beispiel entspricht dem "as"-Cast in Delphi.