bad reloc address (Keine Bibliotheken verwendet)

KN4CK3R

happystudent schrieb:

Oder hat das irgendwelche (mir nicht bekannten) Nachteile? Weil ich find das eigentlich ganz gut so, hoffe also dass nicht

ist nicht das gleiche wie die Trennung in cpp/hpp

Ikaron

Ich hab mal versucht, den Workaround von happystudent zu implementieren. Die bad reloc addresses sind schon mal weg (von den Methoden), der Destruktor von TreeNode mag aber immer noch nicht:

C:\Users\Ikaron\AppData\Local\Temp\ccXoQX1s.ltrans0.ltrans.o:ccXoQX1s.ltrans0.o:(.text+0x162): undefined reference to `TreeNode<int>::~TreeNode()'
C:\Users\Ikaron\AppData\Local\Temp\ccXoQX1s.ltrans0.ltrans.o:ccXoQX1s.ltrans0.o:(.text+0x126): undefined reference to `TreeNode<int>::~TreeNode()'
e:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Ikaron\AppData\Local\Temp\ccXoQX1s.ltrans0.ltrans.o: bad reloc address 0x10 in section `.rdata'
collect2.exe: error: ld returned 1 exit status

Source code ist geupdated im ersten Post.

Wie soll ich denn das Ganze ohne Pointer lösen @nwp3? Was ist so schlimm an new und delete, außer, dass man damit leicht Fehler macht?

Bashar

Der Destruktor ist nirgends implementiert.

Ikaron

Bashar schrieb:

Der Destruktor ist nirgends implementiert.

Ich dachte, man könnte ihn einfach überschreiben, wie eine Methode... Wie kann ich denn den Destruktor umleiten auf die Kindklasse?

Bashar

Der Destruktor der Basisklasse wird vom Destruktor der Kindklasse automatisch aufgerufen. Überschreiben hin oder her.

Ikaron

Bashar schrieb:

Der Destruktor der Basisklasse wird vom Destruktor der Kindklasse automatisch aufgerufen. Überschreiben hin oder her.

Also reicht praktisch ein leerer Destruktor für sowas?
TreeNode* node = new ChildNode();
delete node;
Dann wird ChildNode::~ChildNode() aufgerufen, korrekt?
Ändert allerdings nichts, wenn ich statt

virtual ~TreeNode();

~TreeNode() {};

schreibe. Immer noch das gleiche Problem.

firefly

Ikaron schrieb:

Bashar schrieb:

Der Destruktor der Basisklasse wird vom Destruktor der Kindklasse automatisch aufgerufen. Überschreiben hin oder her.

Also reicht praktisch ein leerer Destruktor für sowas?
TreeNode* node = new ChildNode();
delete node;
Dann wird ChildNode::~ChildNode() aufgerufen, korrekt?

ja aber nur wenn der destruktor von TreeNode virtual ist.

Und bei dir fehlt immer noch die implementierung des Destruktors von Treenode<T>

Ikaron

Hmm, ich habe den Destruktor auf virtual gesetzt, bekomme aber immer noch bad reloc address... Kannst du mir vllt bitte ein konkretes Beispiel geben, wie ich sowas mache?

template <class A> class Base {

public:
	virtual ~Base();
};

template <class A> class Child : public Base<A> {

public:
	~Child() { /* ... */ };
};

Ist das prinzipiell richtig?

Fytch

Ikaron schrieb:

Hmm, ich habe den Destruktor auf virtual gesetzt, bekomme aber immer noch bad reloc address... Kannst du mir vllt bitte ein konkretes Beispiel geben, wie ich sowas mache?
typedef <class A> class Base {

public:
	virtual ~Base();
};

typedef <class A> class Child : public Base<A> {

public:
	~Child() { /* ... */ };
};
Ist das prinzipiell richtig?

ne da steht typedef obwohl du wohl eher template möchtest.

Ikaron

asfdlol schrieb:

Ikaron schrieb:
Hmm, ich habe den Destruktor auf virtual gesetzt, bekomme aber immer noch bad reloc address... Kannst du mir vllt bitte ein konkretes Beispiel geben, wie ich sowas mache?
typedef <class A> class Base {

public:
	virtual ~Base();
};

typedef <class A> class Child : public Base<A> {

public:
	~Child() { /* ... */ };
};
Ist das prinzipiell richtig?
ne da steht typedef obwohl du wohl eher template möchtest.

Ehm upps, klaro, ich verwechsel die zwei immer. Tu so als würde da template stehen.

Bashar

Ob es was bringt, dir zum dritten mal zu sagen, dass der Destruktor nicht implementiert ist? Man kanns ja mal probieren.

Ikaron

Bashar schrieb:

Ob es was bringt, dir zum dritten mal zu sagen, dass der Destruktor nicht implementiert ist? Man kanns ja mal probieren.

Ich verstehe nicht, was daran nicht implementiert sein soll... Habe schon versucht, deinen Tipp umzusetzen, aber am Fehler hat das nie was geändert. Außerdem meckert ja nicht mal der Compiler, sondern nur der Linker.

~BinaryTree() { delete root; delete comparator; };

virtual ~TreeNode() {};
~DataNode() { delete content; delete nextLeft; delete nextRight; };
~ExitNode() {};

Bashar

Ikaron schrieb:

Ich verstehe nicht, was daran nicht implementiert sein soll...

Sorry, hab nicht mitbekommen, dass du den implementiert hast. In deinen letzten Postings seh ich jedenfalls nichts davon.

Habe schon versucht, deinen Tipp umzusetzen, aber am Fehler hat das nie was geändert.

Das bezweifle ich. Poste doch mal die aktuelle Fehlermeldung.

Außerdem meckert ja nicht mal der Compiler, sondern nur der Linker.

Das ist ja auch ein typischer Linkerfehler, weil Funktionen auch in anderen Übersetzungseinheiten definiert werden können (und in der Regel auch werden.)

~BinaryTree() { delete root; delete comparator; };

virtual ~TreeNode() {};
~DataNode() { delete content; delete nextLeft; delete nextRight; };
~ExitNode() {};

Und der Linker sagt immer noch "undefined reference to TreeNode<int>::~TreeNode()"? Kann ich mir kaum vorstellen.

Ikaron

Bashar schrieb:

Ikaron schrieb:

Ich verstehe nicht, was daran nicht implementiert sein soll...

Sorry, hab nicht mitbekommen, dass du den implementiert hast. In deinen letzten Postings seh ich jedenfalls nichts davon.

Ja, ich hab ein wenig rumprobiert, aber es letztendlich wieder gestrichen, da sich nichts geändert hat.

Bashar schrieb:

Habe schon versucht, deinen Tipp umzusetzen, aber am Fehler hat das nie was geändert.

Das bezweifle ich. Poste doch mal die aktuelle Fehlermeldung.

C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x137): undefined reference to `TreeNode<int>::~TreeNode()'
C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x10b): undefined reference to `TreeNode<int>::~TreeNode()'
e:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o: bad reloc address 0x10 in section `.rdata'
collect2.exe: error: ld returned 1 exit status

Bashar schrieb:

Außerdem meckert ja nicht mal der Compiler, sondern nur der Linker.

Das ist ja auch ein typischer Linkerfehler, weil Funktionen auch in anderen Übersetzungseinheiten definiert werden können (und in der Regel auch werden.)

Komisch, bei mir hat sich der Compiler vorhin erst beschwert.

Bashar schrieb:

~BinaryTree() { delete root; delete comparator; };

virtual ~TreeNode() {};
~DataNode() { delete content; delete nextLeft; delete nextRight; };
~ExitNode() {};
Und der Linker sagt immer noch "undefined reference to TreeNode<int>::~TreeNode()"? Kann ich mir kaum vorstellen.

Jap. Fehlermeldung steht oben.

Bashar

Ikaron schrieb:

Bashar schrieb:

Ikaron schrieb:

Ich verstehe nicht, was daran nicht implementiert sein soll...

Sorry, hab nicht mitbekommen, dass du den implementiert hast. In deinen letzten Postings seh ich jedenfalls nichts davon.

Ja, ich hab ein wenig rumprobiert, aber es letztendlich wieder gestrichen, da sich nichts geändert hat.

Was hast du gestrichen? Die Implementierung?

Bashar schrieb:

Habe schon versucht, deinen Tipp umzusetzen, aber am Fehler hat das nie was geändert.

Das bezweifle ich. Poste doch mal die aktuelle Fehlermeldung.

C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x137): undefined reference to `TreeNode<int>::~TreeNode()'
C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x10b): undefined reference to `TreeNode<int>::~TreeNode()'
e:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o: bad reloc address 0x10 in section `.rdata'
collect2.exe: error: ld returned 1 exit status

Besagt eindeutig, dass der Destruktor vom Linker nicht gefunden wurde. Entweder du hast ihn nicht implementiert oder du hast ihn in einer anderen .cpp implementiert.

Bashar schrieb:

Komisch, bei mir hat sich der Compiler vorhin erst beschwert.

Sicher nicht über "undefined references".

Ikaron

Bashar schrieb:

Ikaron schrieb:

Bashar schrieb:

Ikaron schrieb:

Ich verstehe nicht, was daran nicht implementiert sein soll...

Sorry, hab nicht mitbekommen, dass du den implementiert hast. In deinen letzten Postings seh ich jedenfalls nichts davon.

Ja, ich hab ein wenig rumprobiert, aber es letztendlich wieder gestrichen, da sich nichts geändert hat.

Was hast du gestrichen? Die Implementierung?

Naja, ich hab alle Klammern hin und her geschoben... Aber gebracht hat es mir nicht, deswegen hab ich es jetzt einfach so gelassen, wie ich es vorhin geschrieben hab.

Bashar schrieb:

Bashar schrieb:

Habe schon versucht, deinen Tipp umzusetzen, aber am Fehler hat das nie was geändert.

Das bezweifle ich. Poste doch mal die aktuelle Fehlermeldung.
C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x137): undefined reference to `TreeNode<int>::~TreeNode()'
C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o:ccLuai9r.ltrans0.o:(.text+0x10b): undefined reference to `TreeNode<int>::~TreeNode()'
e:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Ikaron\AppData\Local\Temp\ccLuai9r.ltrans0.ltrans.o: bad reloc address 0x10 in section `.rdata'
collect2.exe: error: ld returned 1 exit status
Besagt eindeutig, dass der Destruktor vom Linker nicht gefunden wurde. Entweder du hast ihn nicht implementiert oder du hast ihn in einer anderen .cpp implementiert.

Hmm, magst du mir vllt kurz über Skype helfen? Wenn ein Profi das macht geht es sicher in 5 Minuten...

Ikaron

... Es hat sich doch schon erledigt. Ich habe, intelligent wie ich bin, noch ein Backup-Verzeichnis gehabt, wo ich brav eure Vorschläge befolgt habe... Stellt sich heraus, dass das gar nicht mein Source-Verzeichnis war. Danke noch mal für die Tipps...
(So ein Anfängerfehler, könnte mir grade echt so in's Gesicht schlagen...)

happystudent

KN4CK3R schrieb:

ist nicht das gleiche wie die Trennung in cpp/hpp

Schon, aber hat das irgendwelche praktischen Auswirkungen? Ich konnte bis jetzt nämlich keine feststellen, und ob das dann hinter den Kulissen keine echte Trennung in cpp/hpp ist, ist mir dann ja eigentlich egal.

Hauptsache ich hab halt Header und Implementierung sauber voneinander getrennt, ist sonst eben völlig inkonsistent alles in den Header zu implementieren...

Bashar

Oft nennt man solche Template-(und inline-)Implementierungsdateien dann nicht .cpp, sondern irgendwie .inl oder so was.

happystudent

Ok, und was bringt das dann? Also klar, man sieht an der Dateiendung dass es wohl ne template Klasse ist, aber das behebt ja das eigentliche Problem, nämlich die Inkonsistenz nicht.

Also mich würde eigentlich nur interessieren ob der Ansatz irgendwelche Nachteile gegenüber der klassischen Trennung in cpp/hpp hat.