Pure Virtual Function Called?

Jansen

TS++ schrieb:

Ich poste das Problem sicherheitshalber mal im C++-Forum.

Bitte nicht!
Dafür gibt's das Verschieben, was hiermit durchgeführt wurde.

TS++

@bIce:
Der genannte Vector ist ein Member!!!!!!

bIce

ich meine nicht den Vector sondern den Parameter.

Jester

Was verwendest Du intern für einen Vector? Irgendeinen
vector<Basisklasse von TMyClass2> ?
Falls das sowas ähnlich ist, dann geht Dir beim einfügen des Objekts wahrscheinlich der Anteil der abgeleiteten Klasse verloren, weil Du nur ein Objekt vom Typ der Basisklasse reinspeicherst, der Rest wird sozusagen abgeschnitten.

TS++

@bIce:
Um Gottes Willen!
Bitte google nach "STL" und informier dich über "std::vector". Der Vector ist sowas wie eine Kapselung eines dynamischen Arrays.

@Jester:
Der Vector verfügt ganz billig über folgende Spezifikation:
vector<TMyClass2> myVector;

Ausserdem ist der Vector garnicht das Problem. Ich könnte den gesamten Code aus 'add' auch rauslöschen. Die Parameterliste von 'add' scheint diesen Laufzeitfehler zu verursachen. Nur warum. Wie ich bereits erwähnt habe, tritt der genannte Laufzeitfehler bei einer Referenz nicht mehr auf. Seltsam!!??

Grüße,
TS++

Jester

Vielleicht wäre jetzt der richtige Zeitpunkt uns mal Deine Konstruktoren und Destruktoren zu offenbaren... meine Kristallkugel ist zur Zeit leider in Reparatur.

Möglicherweise ist Dein Beispiel zu stark vereinfacht um den Fehler noch aufzuzeigen. Trau uns mal etwas mehr zu!

PeterTheMaster

warum haelt sich nur keiner an die regel: immer ein minimales compilierbares beispiel posten, dass den fehler noch offenbart. dabei findet man meist auch raus, worans liegt. aber bitte nicht mit bcb spezifischen klassen.

TS++

Ok, ich kümmer mich morgen drum!

Grüße,
TS++

bIce

TS++ schrieb:

@bIce:
Um Gottes Willen!
Bitte google nach "STL" und informier dich über "std::vector". Der Vector ist sowas wie eine Kapselung eines dynamischen Arrays.

Ich weiß was ein vector ist, aber mal ne Frage zu dynamischen Arrays, kannst Du mal die ungekapselte Version präsentieren, ist echt interresant.

@Jester:
Der Vector verfügt ganz billig über folgende Spezifikation:
vector<TMyClass2> myVector;

Ich bin davon ausgegangen das es so aussieht:

vector<TMyClass2*> myVector;

Da es aber nicht der Fall ist, ist auch das meiste davon was ich gesagt habe falsch. :p

TS++

Morgen!

bIce schrieb:

Ich weiß was ein vector ist, aber mal ne Frage zu dynamischen Arrays, kannst Du mal die ungekapselte Version präsentieren, ist echt interresant.

Wie SGI das exakte Innenleben des Vectors realisiert hat, kann ich dir so auf die Schnelle natürlich nicht erklären. Da müsstest du dir schon mal selbst den Quellcode zum vector ansehen.
Wenn du mal selbst ein dynamisch erweiterbares Array erstellen möchtest, so gibt es neben vielen anderen Ansätzen z.B. folgenden einfachen Ansatz:

Dein Array wäre hierbei nichts weiter als ein dynamisch erzeugtes Pointer-Array, wobei dessen Pointer auf dynamisch erzeugte ContentObjekte zeigen. Möchtest du dem Array ein weiteres Element hinzufügen, so erzeugts du dynamisch ein neues PointerArray, übernimmst die Adressen aus dem alten Array, löscht das alte Array und hängst das neue ContentObjekt per Pointer an der letzten Stelle des neuen Pointerarrays ein. Beim Entfernen von Elementen kannst du nach dem gleichen Grundprinzip verfahren. Alles was du zu tun hast, is immer die bereits existierenden Adressen in einem neuen Array anzuordnen und überflüssige Adressen zu entfernen bzw. neue Adressen einzufügen.
(Ist natürlich nur ein recht einfacher Ansatz, aber immerhin recht zuverlässig und nicht all zu schwer realisierbar!)

Was mein ursprüngliches Problem anbelangt, so war ich offensichtlich selbst schuld. Ich hab's jetzt! Ich bin mit dem Debugger nicht weit genug gegangen und hab somit verpasst, dass der Fehler tatsächlich durch den Destruktor des Objekts verursacht wird, das nur temporär in 'add' vorhanden ist. Im Vector wird ja eine Kopie dieses Objekts hinterlegt. Und exakt dieser Destruktor ruft über den Destruktor einer seiner Elternklassen die dort als abstrakt deklarierte Methode 'clear()' auf. 'clear()' wird in meiner Klassenhierarchie zwar in den entsprechenden Kindklassen implementiert, nur wenn der Methodenaufruf im Destruktor der Elternklasse stattfinden, nützt mir das natürlich wenig.
Was lernen wir daraus: Ruhig mal zu Ende Debuggen!

Interessanterweise stellt der Compiler von VC bereits beim Linken fest, dass der Aufruf einer abstrakten Routine droht. Der BorlandCompiler erkennt das nicht. Er übersetzt das, wie bereits erwähnt, problemlos, linked ohne Schwierigkeiten und hat dann erst zur Laufzeit Probleme!

Na, ja. Jetzt weiss ich wenigstens woran ich bin!

Danke!

Grüße,
TS++