Ergebnis des geerbten Konstruktors verschwindet wieder

[Mikkey]

ich habe ein sehr ungewöhnliches Problem:

Einige Klassen, die aufeinander aufgebaut sind:
TBase <- TEditable <- TTriggerBase <- [TTriggerA, TTriggerB]

TTriggerA wird in einem Projekt verwendet und alles läuft gut.

TTriggerB wird in einem anderen Projekt verwendet, da tritt folgendes Verhalten auf:
Der Konstruktor von TTriggerBase füllt die Daten-Member, bei der Rückkehr zum Konstruktor von TriggerB werden diese Inhalte wieder gelöscht.

Zur Lokalisierung des Fehlers habe ich eine statische Variable 'beingCreated: ' angelegt, die eine Referenz auf das konstruierte Objekt trägt.
Steppt man nun durch die Konstruktoren, so fällt auf, dass sich zwar die Werte in self ändern, nicht aber die in 'beingCreated'. Dies gilt aber nur für die Werte in der Ebene TTriggerBase. Die Werte der Vorfahren TBase und TEditable erscheinen über beide Referenzen (s. Bild).

Delphi-Quellcode:

constructor TBase.Create();
begin
  inherited Create();
  Inc(g_ObjectId);
  m_objId := g_ObjectId;
  m_Version := 1;
end;


constructor TEditable.Create();
begin
  inherited Create();
  m_IsModified := false;
end;


constructor TTriggerBase.Create(id: Integer; name: String; wait: single;
                            bCombineAll: Boolean; fehlerAktion: Integer);
begin
  inherited Create();
  m_TriggerID      := id;                                                
  m_Name           := name;                                              
  m_Timeout        := wait;
  m_CombineAll     := bCombineAll;
  m_FehlerAktion   := fehlerAktion;
  m_Conditions     := TObjectList.Create(false);                         
  m_Checks         := TObjectList.Create(false);                         
  m_Nachfolger     := TObjectList.Create(false);                         
  m_Vorgaenger     := nil;
end; //  <<=== s. Grafik


constructor TTriggerA.Create(id: Integer; name: String; wait: single;
                            bCombineAll: Boolean; fehlerAktion: Integer);
begin
  inherited Create(id, name, wait, bCombineAll, fehlerAktion);
  m_TimeActivated := 0;                                                  
  m_TimeTriggered := 0;
  m_isLogged := false;                                                   
end;


var beingCreated: TTriggerB;

constructor TTriggerB.Create(id: Integer; name: String; wait: single;
                            bCombineAll: Boolean; fehlerAktion: Integer);
begin
  beingCreated := self;
  inherited Create(id, name, wait, bCombineAll, fehlerAktion);
  m_XPosition      := 0;
  m_TimeTriggered  := 0;
  m_DeletedObjects := TObjectList.Create(false);                         
  m_AddedObjects   := TObjectList.Create(false);
end;

Hat jemand eine Idee, woran das liegen könnte und (vor allem) wie man das Verhalten korrigieren kann?

[Mikkey]

Thema ist erledigt, nachdem auf andere Merkwürdigkeiten aufgetreten sind, ist mir endlich :oops: aufgefallen, dass in der abgeleiteten Klass die Datenfelder erneut deklariert waren.

Was mich aber schon wundert:

• Dem Compiler ist das nicht einmal einen Hinweis wert.
  
• Der Destruktur der Basisklasse seine selbst angelegten TObjectList-en nicht abgeräumt hat.

[jaenicke]

Zitat:

Zitat von Mikkey (Beitrag 1233130)

Was mich aber schon wundert:

Dem Compiler ist das nicht einmal einen Hinweis wert.

Doppelte Bezeichner kommen ja öfter vor, woher sollte der Compiler wissen wann er darauf hinweisen muss?
Er nimmt einfach den vom Scope her am nächsten deklarierten.

In so einem Fall (unerwarteter Inhalt einer Variablen) benenne ich die Variable einfach um und schaue wer da noch alles drauf zugreift. Dabei wäre dann aufgefallen, dass die abgeleitete Klasse weiter kompiliert.

[Der schöne Günther]

Genau den Fall hatte ich neulich aber auch und mich ebenfalls geärgert, dass man hier wenigstens einen Hinweis bekommen könnte wenn man so einen Fehler macht.

Das wird man ja in den seltensten Fällen wirklich so wollen.

[Mikkey]

Zitat:

Zitat von jaenicke (Beitrag 1233138)

Doppelte Bezeichner kommen ja öfter vor, woher sollte der Compiler wissen wann er darauf hinweisen muss?

Bei Methoden bringt er ja auch die Hinweise, wenn man die virtuals, overloads, overrides und reintroduces nicht in der genehmen Art und Weise verteilt hat. Außerdem kommen bei mir (vorsätzlich) nie Variablen mit gleichen Namen bei Klassen in gerader Linie vor.

Zitat:

In so einem Fall (unerwarteter Inhalt einer Variablen) benenne ich die Variable einfach um und schaue wer da noch alles drauf zugreift. Dabei wäre dann aufgefallen, dass die abgeleitete Klasse weiter kompiliert.

Dann hätte schon die Basisklasse nicht kompiliert - in der abgeleiteten Klasse hätte ich die Variablen ja nicht gesucht.