Allgemeines zum Einbinden von Dateien in Visual Studio Projekte
-
Hallo,
ich habe eine grundlegende Frage zum Erstellen von C++ Projekten in Visual Studio.
Zur besseren Übersicht habe ich mir einen Ordner für meinen eigenen Code angelegt, darin zwei Unterordner "include" und "src". Diese beiden Ordner habe ich im Visual Studio unter "Extras-Optionen-Projekte und Projektmappen-VC++-Verzeichnisse" als Suchpfade eingetragen.
Ich eröffne nun ein neues Projekt mit einer main.cpp und inkludiere eine .h Datei aus meinem eigenen Pool. Diese wird auch durch meinen Suchpfad gefunden. Allerdings wird die .cpp Datei nicht gefunden, obwohl der Suchpfad korrekt ist. Es kommt zur Fehlermeldung:
"error LNK2019: Verweis auf nicht aufgelöstes externes Symbol"
Wenn ich die .cpp Datei explizit in meinem Projekt hinzufüge, dann klappt es. Bedingung ist nur, dass ich die Datei "stdafx.h" in die .cpp Datei einbinde
Soweit so gut, meine Frage ist nun, muss ich denn die .cpp Dateien immer ins Projekt einbinden?
Warum funktioniert der Suchpfad nicht automatisch so wie bei der .h Datei, die muss ich nicht ins Projekt einbinden, inkludieren per #include genügt?
Warum muss ich die .cpp Dateien die bei Visual Studio dabei sind nicht von Hand einbinden, da genügt ja auch das inkludieren der .h Dateien.Ist vielleicht ganz einfach zu klären, wäre schön.
Grüße xtr23
-
In deinem Header steht ja nirgendwo "damit diese Definitionen funktionieren, kompiliere bitte Datei xyz". Dein Visual Studio wüsste also gar nicht, nach welcher Datei es die Suchpfade durchsuchen soll. Du musst die cpp-Datei deinem Projekt hinzufügen, damit sie kompiliert und zur exe hinzugelinkt wird. Sonst fehlen zu deinen Prototypen die Implementationen.
-
Ich hatte angenommen, dass alle Dateien die in einem Suchpfad angegeben sind auch durchsucht werden. Wozu ist sonst der Suchpfad gut?
-
Für Header, libs...
-
Es gibt ja auch nen Suchpfad speziell für Quelldateien. Einen Zweck konnte ich gerade ausmachen. Ich habe die Datei assert.c (Ist bei VS dabei.) aus dem Standardordner in meinen Ordner verschoben und sie wurde problemlos gefunden. Der Suchpfad funktioniert also.
Was ich nich nicht recht verstehe ist, woher der Compiler jetzt weiß, dass wenn ich assert.h inkludiere, er nach assert.c suchen muss. Oder sind das einfach nur spezielle Einstellungen, die der Compiler für die von der Entwicklungsumgebung mitgelieferten Quelldateien hat?
-
assert.c will er gar nicht verwenden!
Warum auch. C und CPP Dateien werden ur verwendet, wenn Du Sie per #include einfügst oder in das Projekt einfügst.Wenn die eine belieibie CRT Source Datei nimmst, dann interessiert sich der Compilker nicht für sie, außer Du fügst diese in Dein Projekt ein und dann bekommst Du 100% einen Fehler, weil Symbole doppelt gefunden werden. In Deinem Projekt und in der Source.
-
Du hast mich wahrscheinlich nicht richtig verstanden. Hier mal ein Minimal-Beispiel:
#include "stdafx.h" #include <assert.h> int _tmain(int argc, _TCHAR* argv[]) { assert(false); return 0; }
Das Programm ist natürlich sinnlos, aber obwohl die Quelldatei "assert.c" nicht im Projekt eingebunden ist, findet sie der Compiler. Das sehe ich, wenn ich mit F11 den Code durchgehe. Das funktioniert wenn die "assert.c" im Standardordner liegt, aber auch wenn sie in dem von mir per Suchpfad angegeben Ordner liegt.
Was ich daran nicht verstehe ist, warum der Compiler die "assert.c" findet, auch wenn sie nicht im Projekt hinzugefügt wurde und dagegen meine eigenen Quelldateien nicht. Wenn der Compiler meine eigene Quelldatei (z.B. meine.cpp) finden soll, muss ich sie im Projekt hinzufügen. Der Befehl #include <meine.h> allein genügt nicht. Dann kommts zu dem oben genannten Fehler:
"error LNK2019: Verweis auf nicht aufgelöstes externes Symbol"
-
Der Linker holt sich "assert.c" nicht über den Suchpfad sondern über die libcmtd.lib, welche die entsprechende Funktion als Teil C-Laufzeitbibliothek enthält. Der Suchpfad für Quelldateien ist in erster Linie für den Debugger wichtig, um bei F11 die richtige Datei zu finden.
-
Vielen Dank, das wollte ich wissen. War also doch ganz leicht