Linker-verträgliche Sourcenorganisation

[MarcE]

Hallo zusammen!

Ich habe es in meinem Projekt mit drei Arten Klassen zu tun:

1.) Die Eigentlichen Projekt-Klassen
2.) selbst entwickelte Komponenten, die vom Projekt benutzt werden
3.) Hilfsklassen, die von den Komponenten benutzt werden und z.B. zur Kommunikation mit der Außenwelt, also auch den Projekt-Klassen, dienen.

Bis jetzt hatte ich das ganze so organisiert, dass ich die Komponenten und die Hilfsklassen in einem gemeinsamen Verzeichnis gespeichert hatte und das Projekt in einem anderen.
Dem dclusr-Package hatte ich sowohl die Komponenten als auch die Hilfsklassen hinzugefügt und den Suchpfad in den Optionen auf das Kompnenten- und Hilfsklassenverzeichnis gesetzt.
Dem Projekt hatte ich die Projektdateien und die Hilfsklassen hinzugefügt und den Suchpfad zum Auffinden des Hilfsverzeichnisses gesetzt.

Das ganze hat halbwegs funktioniert, auch wenn das Compilieren der Komponenten manchmal mehrere Anläufe gebraucht hat, bis der Linker es auf der Reihe hatte.

Inzwischen tut (ohne das ich einen konkreten Auslöser dafür erkennen könnte) gar nichts mehr. Der Linker meldet hartnäckige "unresolved externals". Auch "neu Erzeugen" und das Löschen der .obj-Dateien bringt nichts.

Hat jemand einen Vorschlag, wie ich meine Sourcen am besten organisiere, damit der arme Linker wieder mit kommt?

Gruß
Marc

[akari]

Hallo

im Grunde hört sich die Aufteilung schon gut an, wobei zu beachten ist, das du von installierten Komponenten nur die Headerdateien zugänglich machen mußt, und nicht die cpp-Datei dem die Komponenten benutztendem Projekt hinzufügen mußt.

Das ganze hat halbwegs funktioniert, auch wenn das Compilieren der Komponenten manchmal mehrere Anläufe gebraucht hat, bis der Linker es auf der Reihe hatte.

Inzwischen tut (ohne das ich einen konkreten Auslöser dafür erkennen könnte) gar nichts mehr. Der Linker meldet hartnäckige "unresolved externals". Auch "neu Erzeugen" und das Löschen der .obj-Dateien bringt nichts.

Ich glaube, diese Aussagen sind zu wage, als das jemand hier den Fehler findet.
Mein Tip : Projekt sauber neu zusammenstellen.

bis bald
akari

[MarcE]

Hallo,

ich hab' den Fehler inzwischen gefunden. Falls jemand 'mal das gleiche Problem hat und hier nach "unresolved external" sucht, schreib' ich's kurz hin:

Ich habe eine Oberklasse mit "virtual"-Methoden. Bei der Implementierung einer Unterklasse hatte ich dann beim Code für die Methoden vergessen, den Klassennamen vor die Methode zu stellen, also

MeineMethode()
{
}

statt

TMeineUnterKlasse::MeineMethode()
{
}

so dass die Methode nicht der Klasse zugeordnet werden konnte. So kam es zu dem beschriebenen Fehler.

Gruß
Marc

PS: Bei einer objektorientierten Sprache würde ich mir eigentlich eine Warnung wünschen, wenn Routinen völlig losgelöst von einer Klasse im Code rumschwirren...