bad reloc address (Keine Bibliotheken verwendet)
-
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 statusBesagt 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...
-
... 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...)
-
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...
-
Oft nennt man solche Template-(und inline-)Implementierungsdateien dann nicht .cpp, sondern irgendwie .inl oder so was.
-
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.
-
Das ist doch eine akademische Frage, da die getrennte Übersetzung bei Templates nicht funktioniert.
-
In IDEs werden üblicherweise .cpp-Dateien vom Compiler kompiliert, während .hpp und .inl als Header angeschaut werden. Von daher macht es schon einen Unterschied, welche Dateiendung du benutzt.
-
Nexus schrieb:
In IDEs werden üblicherweise .cpp-Dateien vom Compiler kompiliert, während .hpp und .inl als Header angeschaut werden. Von daher macht es schon einen Unterschied, welche Dateiendung du benutzt.
Ok, also wenn ich statt TemplateClass.cpp ein TemplateClass.inl verwende ist dass das selbe als hätte ich alles in den Header implementiert?
Das wäre dann ja optimal, da man trotzdem noch die physikalische Trennung in zwei verschiedene Dateien hätte.
-
happystudent schrieb:
Ok, also wenn ich statt TemplateClass.cpp ein TemplateClass.inl verwende ist dass das selbe als hätte ich alles in den Header implementiert?
Wenn du am Ende von
ClassTemplate.hpp(es heisst Klassentemplate, nicht Templateklasse) ein#include "ClassTemplate.inl"hast, ja. Das ist zumindest der übliche Weg, um Separation mit Templates zu bewahren.
-
Ok cool, Danke. Wieder was gelernt
