Linker Error

Ad aCTa

Hallo!
Ich kann mir gerade das Verhalten meines Linkers nicht erklären. Der Aufbau ist so:

header.hpp (enthält Deklarationen und Klassendefinitionen, includiert impl.hpp ganz am Ende)
impl.hpp (enthält Implementierungen von Templates)

impl.cpp (includiert header.hpp, enthält Implementierung der Deklarationen aus header.hpp)
main.cpp (includiert header.hpp, nutzt die Klassen aus header.hpp)

Nun befindet sich in header.hpp etwa sowas:

class X {
public:
   inline unsigned get() const;
private:
   unsigned res_;
};

Und in impl.cpp dann

unsigned X::get() const {
    return res_;
}

Ist alles spitze. Sobald ich nun jedoch X::get() in impl.hpp (dort, wo Templates definiert werden) oder auch in main.cpp aufrufe, gibt's Linker-Errors. Sie verschwinden, wenn ich in impl.cpp die get() einmal aufrufe, also kompiliert er sie anscheinend gar nicht, wenn ich sie nicht in impl.cpp aufrufe. Aber wieso? Ich möchte get() eigentlich gar nicht in impl.cpp aufrufen.

Dass Funktionen nicht kompiliert werden, wenn man sie in der Übersetzungseinheit nicht braucht, kenne ich nur von Templates, aber von normalen Memberfunktionen?

Ich bin ratlos.

unskilled

zeig mal bitte die LNK-fehlermeldungen.

des weiteren kannst du mal das inline in der deklaration wegmachen - bringt eh nichts.

bb

Ad aCTa

Naja, der klassiche Fehler des Linkers:

error LNK2019: unresolved external symbol "public: unsigned int __thiscall X::get(void)const " (?get@X@@QBEIXZ) referenced in function "main" usw. -übliches kryptisches Zeug-

Wenn man nur unsigned schreibt ist immer ein unsigned int gemeint?

Ad aCTa

Ja.

Mr X

Vielleicht liegts am inline

Ad aCTa

Ist auch schon weg. Optimiert der da irgendwas rum?

mgaeckler

Ad aCTa schrieb:

Ist auch schon weg. Optimiert der da irgendwas rum?

Wenn das inline schon weg ist, muß es etwas anderes sein, das Du uns hier vorenthalten hast. Der Codeschnipsel, den Du hier zeigst, ist nämlich in Ordnung.

1. Ist der Code wirklich übersetzt worden?
2. Was macht der Präprozessor?
3. Wenn ich solche Probleme habe, prüfe ich gerne mal mit

#error "blablabla"

ob die Funktion auch wirklich übersetzt wird.

4. Ansonsten such mal nach vergessenen ;. Die verursachen auch gerne mal unerklärliche Fehler.

Viel Glück

Martin

Ad aCTa

> Wenn das inline schon weg ist, muß es etwas anderes sein, das Du uns hier vorenthalten hast.

Nun, die Funktion ist Member einer abgeleiteten Klasse mit Laufzeitpolymorphie (wobei die Funktion non-virtual ist).

> 2. Was macht der Präprozessor?

Nur include-Guards

> 3. Wenn ich solche Probleme habe, prüfe ich gerne mal mit

#error "blablabla"

ob die Funktion auch wirklich übersetzt wird

Wie soll das funktionieren? Ich weiß genau, dass die Funktionen nicht kompiliert werden, wenn sie in der Übersetzungseinheit nicht gebraucht werden. Ein nachgucken in den Objektdateien hat das bestätigt.

> 4. Ansonsten such mal nach vergessenen ;. Die verursachen auch gerne mal unerklärliche Fehler.

Linker-Fehler? Das kommt niemals so durch 'nen Compiler.

unskilled

Ad aCTa schrieb:

> 3. Wenn ich solche Probleme habe, prüfe ich gerne mal mit

#error "blablabla"

du sollst irgendwo in die *.cpp #error bla schreiben - und dann wirst du vermutlich sehen, dass die cpp gar nicht erst geparst wird?!

evtl. baust du auch endlich mal ein minimales kompilierendes bsp., weil deine angegebenen codeschnipsel nicht diesen fehler verursachen sollten, die du schilderst...

bb

mgaeckler

Ad aCTa schrieb:

> 3. Wenn ich solche Probleme habe, prüfe ich gerne mal mit

#error "blablabla"

ob die Funktion auch wirklich übersetzt wird

Wie soll das funktionieren? Ich weiß genau, dass die Funktionen nicht kompiliert werden, wenn sie in der Übersetzungseinheit nicht gebraucht werden. Ein nachgucken in den Objektdateien hat das bestätigt.

Wenn Du schon weißt, daß sie nicht übersetzt werden, dann tu was dagegen.

mfg Martin