Constructor stürzt mich ins Verderben

[ZahnschleischbluterMurph]

Hallo zusammen,

ich bin grad am Verzweifeln. Ich habe mehrere Objektlisten und packe da immer kräftig meine Ojekte drauf.

Unit Typen:

Delphi-Quellcode:

Type TTabu = class(TObject)
t:integer;
s:integer;
...
Constructor Create;
end;

Type TTabu_Liste = class(TOjectList)
published function GetItems(i:integer):TTabu
end;

...

implementation

constructor TTabu.Create();
begin
inherited create;
end;

function TTabu_Liste.GetItems(i : integer):TTabu;
begin
result := TTabu(inherited Items[i]);
end;

Soweit so gut. Funktioniert auch alles ganz prima. Ich deklariere die Tabus (Tabu : TTabu, lege einige an (Tabu := TTabu.Create), weise ihnen Werte zu (Tabu.t := 7) und packe sie in die Liste (Tabu_liste.add(Tabu)).

Irgendwann allerdings schmiert das Programm beim Aufruf des Constructors ab. Also nach Tabu := TTabu.Create springt er noch in den Constructor und hängt sich dann auf. Nach ein paar Sekunden kommt dann eine Fehlermeldung 'Zugriffsverletzung bei ...: Schreiben von Adresse ...'.

Das Schlimme ist, dass es irgendwie willkürlich passiert. Wenn ich bspw. beim Typen noch eine variable k: single mit reinstecke, hängt sich das Programme einige Schleifen früher auf. Wenn ich die Objekte nach der Übernahme in die Liste zerstöre, dann hat das nur den Effekt, dass das Programm bei einem anderen Constructor abschmiert.

Hab echt keinen Plan, was da schief läuft und wäre Euch dankbar für Tipps. Kann ich im Constructor etwas ändern?

Eines jedoch vorweg: dynamische Arrays von records sind nicht drin. Damit hatte ich ursprünglich alles gemacht, jedoch war der Speicherbedarf ein wenig zu hoch geworden (wegen ständiger Längenanpassung).

Falls wichtig: ich nutze Delphi 7.

[Hansa]

was soll das inherited create; ? Und das inherited mit dem Item ? Den TObject-Constructor gibt es zwar, der ist aber leer. Wenn dieser leere Constructor aufgerufen werden soll, dann wenigstens nur mit inherited; Man kanns in dem Fall aber auch sein lassen. Ich lasse es trotzdem allerdings nicht sein, weil die theoretische Möglichkeit besteht, dass zwischen meinem TXYObject und dem Original-TObject noch eine Zwischenschicht reinkommt. Wegen dieser müsste dann nachträglich wohl doch noch inherited; reingeschrieben werden. Allerdings nur das und nicht noch create dahinter. Das ist jedenfalls der einzige Unterschied, den ich an dieser Stelle zu meinem funktionierendem Source sehe. 8)

P.S.: sehe, da steht ja sogar constructor TTabu.Create(); Wozu die () ? Befürchte, dass Delphi sogar dadurch aufs Glatteis gejagt wird.

[ULIK]

Hm, scheint erst mal alles richtig zu sein. Kannst Du das 'irgendwann' näher definieren (in Anzahl der TTabu Instanzen, die Du erzeugt hast)? Bzw. kannst Du den Code posten, indem Du die Elemente erzeugst und einhängst?
Wegen den Speichergeschichten: Binde FastMM ein.

Grüße,
Uli

[jaenicke]

Zitat von Hansa:

was soll das inherited create; ? Und das inherited mit dem Item ? Den TObject-Constructor gibt es zwar, der ist aber leer. Wenn dieser leere Constructor aufgerufen werden soll, dann wenigstens nur mit inherited;

Das ist doch egal. Und um genau zu sein geht es z.B. bei variablen Parametern in der überschriebenen Methode gar nicht nur mit inherited;! Deshalb ist das schon völlig richtig, schließlich spricht man damit ja explizit diese Methode in der Elternklasse an.

Zitat von Hansa:

P.S.: sehe, da steht ja sogar constructor TTabu.Create(); Wozu die () ? Befürchte, dass Delphi sogar dadurch aufs Glatteis gejagt wird.

Auch das ist korrekt. Ganz alte Delphiversionen kannten das wohl noch nicht, aber zumindest ab Delphi 6 ist diese Schreibweise bei Methoden ohne Parameter vollkommen normal. Auch ich benutze das oft, weil man damit deutlich Methoden von Eigenschaften und Variablen unterscheiden kann, unabhängig vom Namen.

Was das inherited in GetItems soll, ist mir allerdings nicht klar, denn schließlich gibt es ja kein Items in der neuen Klasse, so dass das ohnehin klar ist, was gemeint ist.

Ich sehe in den geposteten Schnipseln aber erstmal keinen echten Fehler.

Die beschriebenen Effekte deuten jedenfalls auf ein Speicherproblem. Überschriebener Speicher z.B., aber das liegt nicht an dem geposteten Code.
Dass es Fehler gibt, wenn du die erstellten Objekte nach dem Hinzufügen freigibst, ist klar, denn dann sind die ja in der Liste auch kaputt.

Vielleicht hilft es, wenn du versuchst den entsprechenden Code isoliert zu testen bzw. zu kürzen. Wenn das nicht mehr viel Code wäre, in dem dann immer noch der Fehler auftritt, könntest du den dann komplett posten.

[mkinzler]

Constructor Create; virtual; override;

[jaenicke]

Zitat von mkinzler:

Constructor Create; virtual; override;

Erstens muss das override vor dem virtual stehen, zweitens kann man den Konstruktor von TObject nicht überschreiben...

[mkinzler]

Zitat:

zweitens kann man den Konstruktor von TObject nicht überschreiben...

Aber der von TTabu soll das

[ZahnschleischbluterMurph]

Guten Morgen,

schon einmal vielen Dank für die Antworten!

@Hansa: habs irgendwann einmal so gelernt und niemals hinterfragt. Aber gut zu wissen, dass ich mir die Tipperei sparen kann. Hab den überflüssigen Kram rausgeschmissen, aber das hat mein Problem noch nicht gelöst.

@Ulik: Irgendwann klingt fast nach viel, ist es aber nicht. Ich führe 5 Listen und wenn es zum Abbruch kommt, habe ich im Schnitt jeweils rund 20-30 Elemente drin. Aber kurz zu FastMM - war das eine Idee für die dynamischen Arrays?

@jaenicke: Momentan ist der Code noch etwas zu umfangreich, um ihn zu posten, aber ich probiere mal, Deinen Rat mit dem Isolieren umzusetzen, und melde mich im Laufe des Tages!

@mkinzler: ähm, vielleicht stelle ich mich jetzt zu doof an, aber wo muss ich denn 'override' und 'virtual' schreiben?!

Ncoh einmal vielen Dank an alle!

[jaenicke]

Zitat von mkinzler:

Zitat:

zweitens kann man den Konstruktor von TObject nicht überschreiben...

Aber der von TTabu soll das

Probiers aus, AFAIK wirst du override bei einer direkt von TObject abgeleiteten Klasse nicht benutzen können. Beim Desktruktor ja, aber nicht beim Konstruktor.

[ULIK]

Zitat von ZahnschleischbluterMurph:

@Ulik: Irgendwann klingt fast nach viel, ist es aber nicht. Ich führe 5 Listen und wenn es zum Abbruch kommt, habe ich im Schnitt jeweils rund 20-30 Elemente drin. Aber kurz zu FastMM - war das eine Idee für die dynamischen Arrays?

Ja, aber generell ist FastMM immer gut (alleine schon wegen der Möglichkeit, sich Speicherlecks anzeigen zu lassen)

Zum eigentlichen Problem: bei den paar Instanzen sollte da eigentlich nichts anbrennen. Versuch mal den Code zu extrahieren, mit dem Du die Instanzen erzeugst und einhängst. Vieleicht sieht man hier was.


Grüße,
Uli