3. Splitten von Header und Source File

Splitten von Header und Source File

  • T

    Hi, wie funktioniert das den richtig?

    Ich hab die Datei hallo.cpp (liegt im Verzeichnis : "C:\Code\Test") mit diesem Code :

    #include <iostream>
#include "C:\Code\Klassen\CloseNot.h"
using namespace std;
int main()
{
cout << "Hallo"<<endl;
CloseNot();
}

    Obwohl es ein Verzeichnis gibt mit genau dem Verzeichnis und dem Header welches ich oben inkludiert habe, kommt beim compilieren der Fehler : No such file or directory.

    Kann mir jemand sagen wie das richtig geht ?

    Edit, ok ich habs, so muss es heißen :

    #include "../Klassen/CloseNot/CloseNot.h"

    Immerhin bekomme ich keine linker Fehlermeldung mehr, aber schon hab ich das nächste Problem. Beim kompilieren, bekomme ich die Meldung : C:\Code\Test\Hallo.exe does not exist / is not executable

    Also der Inhalt der CloseNot.h sieht so aus :

    #ifndef CLOSENOT_H
#define CLOSENOT_H
void CloseNot();
#endif

    der Inhalt der CloseNot.c :

    #include "CloseNot.h"

void CloseNot()
{
cin.clear():
cin.ignore(cin.rdbuf()->in_avail());
cin.get();
}

    Weiss jemand was da schief läuft ?

    0
  • *

    Du musst schon die CloseNot.c einbinden!

    0
  • T

    ach oh mein Gott , ok , danke geht jetzt, ich dachte man muß die headers einfügen...

    0
  • ?

    Ich hoffe mal du machst jetzt kein

    #include "../Klassen/CloseNot/CloseNot.c"

    ...... sondern linkst das nur dazu

    0
  • T

    ähh doch genau so hab ichs gemacht ^^ . Also ich muß beides einbinden , header und Source ? Warum funktioniert es auch ohne einbinden des headers ? Gibts ne Regel für die Reihenfolge ? Also header oder source zuerst einfügen ?

    0
  • P

    Mit einbinden war nicht gemeint, dass du mit #include die Datei mit der Implementierung in die eigentliche Source-Datei deines Programmes ziehst. Wenn man das so macht, verliert man ja die meisten Vorteile der Aufteilung in Header und Source-Dateien, z.B. dass man nicht jede Datei neu kompilieren muss, die die Funktionen verwendet, nur wenn sich die Implementierung und nicht die Schnittstelle ändert.

    Mit einbinden war gemeint, dass du deine Source-Datei (CloseNot.c) irgendwie in das Projekt einfügen musst. Wie das genau geht, hängt davon ab, welchen Compiler, bzw. welche IDE du verwendest.

    Außerdem ist es beim includen von Headern normalerweise schlecht, einen absoluten Pfad anzugeben... Hängt aber von der konkreten Situation ab.

    Felix

    EDIT: Der Grund, warum es auch funktioniert, wenn man nur die Source-Datei und nicht die Header-Datei ber include einfügt, ist der, dass die Definitionen in der Source-Datei auch gleichzeitig als Deklarationen funktionieren. Wie gesagt sollte man die Source-Datei aber nicht includen, sondern getrennt übersetzen und dann in das Projekt hinzufügen/dazulinken.

    0
  • T

    Also ich benutz gvim mit dev-cpp kompiler, und die hallo.cpp sieht halt jetzt so aus :

    #include <iostream>
#include "../Klassen/CloseNot/CloseNot.h"
#include "../Klassen/CloseNot/CloseNot.c"
using namespace std;
int main()
{
cout << "Hallo"<<endl;
CloseNot();
}

    Es funktioniert doch so oder nicht ?
    Also zumindest klappt das kompilieren ohne Probleme. Der Vorteil von dem Aufteilen ist doch hauptsächlich der, das der Code übersichtlicher wird und ich auf diese Weise in jedes meiner Programme die CloseNot includieren kann. Oder ?

    0
  • O

    Nein eben genau so ist es falsch!
    Du hast 3 Dateien, zwei Sourcedateien (.c/.cpp/.cxx) und eine Headerdatei (.h/.hpp/.hxx). Überall wo die Deklarationen(!) benötigt werden bindest du die Headerdatei mittels #include ein. Kompiliert wird jede Sourcedatei einzeln. Dem Linker musst du anschließend aber alle Sourcedateien angeben, damit er daraus eine Executable erstellt.
    Bei IDEs wie Dev-Cpp macht man das indem man ein Projekt erstellt und die Header und Sourcedateien dort hinzufügt.

    0
  • D

    Du inkludierst NIE die Source (ausser bei Templates).

    Du linkst höchstens die anderen Source Dateien dazu. Das musst du aber über die IDE machen oder irgendwo als Parameter angeben.

    Das aufteilen ist aus dem Grund, dass ein benutzer einer Funktion oder Klasse lediglich die genaue Deklaration kennen muss, um sie zu benutzen.

    0
  • ?

    Hi toxor,

    bei dieser Art geht leider der Sinn von Header-Dateien verloren.
    Sie sollen dir helfen Definition und Implementierung zu trennen.
    Leider kenne ich gvim nicht, aber wenn die Datei in deinem Projekt liegt,
    sollte sie eigentlich mitgelinkt werden, so dass du die Source-Datei nicht
    inkludieren muss. Wenn es sich um eine (oder mehrere) externe Datei(en) handelt,
    dann erstellt man in einem separaten Projekt eine Library, die man
    dann mitlinkt.
    Das Hauptprobem beim Includieren von Source-Dateien liegt darin, dass der
    Linker sich (wegen doppelten Sourcen) beschweren wird, wenn du zwei Dateien
    zusammen linkst, die die gleiche Source-Datei includieren.

    Gruß,
    CSpille

    0
  • T

    Hey danke für die vielen Antworten, aber wie ich das Problem nun lösen soll weiss ich leider immernoch nicht. Ich benutzte ja nicht die IDE des Dev-CPP sondern nur den Compiler. Zum Coden benutze ich den gvim (lediglich ein Texteditor mit Syntaxh.).
    Soweit ich das jetzt verstanden habe soll ich das Sourcefile nicht includieren. Ok, dann erkennt er es aber auch nicht. Also soweit ich euch nun verstanden habe muß ich das Sourcefile auf einem anderen Weg einbinden. Ich hab jetzt einfach mal die beiden Files, "CloseNot.h" und "CloseNot.c" in das selbe Verzeichnis kopiert, wo die "hallo.cpp" lagert. Allerdings ohne die "CloseNot.c" zu inkludieren bekomme ich Fehler...das ist doch sch...

    0
  • T

    Also wenn ich direkt über die IDE vom Dev mache, klappts so wie ihr gesagt habt. Jetzt stellt sich halt mir trotzdem die Frage, wie man das mit normalen Editoren löst.

    0
  • P

    Was bedeutet denn, du benutzt nur den Compiler von Dev-Cpp? Wie rufst du den denn auf? Über die Kommandozeile (bzw. direkt von vim aus), oder startest du erst Dev-Cpp und öffnest die Source, die du dann kompilierst?

    Wenn du sowieso gvim als Editor benutzt, könntest du dir auch den MingW runterladen und den als Compiler benutzen. Der wird relativ häufig verwendet, das heißt, man könnte dir besser helfen. Dev-Cpp benutzt intern nämlich auch MingW (allerdings wahrscheinlich eine etwas ältere Version)...

    Felix

    P.S.: Mit g++ würdest du erst beide Sourcen einzeln kompilieren, also etwa

    g++ -c hallo.cpp -o hallo.o
g++ -c CloseNot.c -o CloseNot.o

    und dann alles zu einem Programm linken, mit

    g++ hallo.o CloseNot.o -o hallo.exe

    P.S.: Wieso nennst du CloseNot.c so und nicht CloseNot.cpp, wenn es doch eine C++ Quellcode-Datei ist?

    0
  • T

    Es gibt ein C/C++ Plugin für den vim, so kann ich, nachdem ich den compiler vom Dev über die Windows Umgebungsvariablen eingebunden habe, aus vim heraus kompilieren.
    MinGW braucht mir zuviel Platz,deswegen nutz ich den Dev.

    Zu dem CloseNot.c : Ich hab so in einem C++ Tutorial gelesen, keine Ahnung was das sollte. Hab mich auch schon gewundert, warum das Source File .c heisst. Ok dann änder ich das mal.

    0
  • K

    Phoemuex schrieb:

    P.S.: Mit g++ würdest du erst beide Sourcen einzeln kompilieren, also etwa

    g++ -c hallo.cpp -o hallo.o
g++ -c CloseNot.c -o CloseNot.o

    und dann alles zu einem Programm linken, mit

    g++ hallo.o CloseNot.o -o hallo.exe

    P.S.: Wieso nennst du CloseNot.c so und nicht CloseNot.cpp, wenn es doch eine C++ Quellcode-Datei ist?

    Oder einfach
    g++ hallo.cpp CloseNot.cpp -o hallo.exe

    0
  • T

    Ja wie gesagt, ich kann mit dem C++ plugin über einen einfachen Button kompilieren, ohne g++ über eine Konsole zu starten, daher weiss ich nicht wie da mehrere headers hinzufügen kann ...

    0
  • D

    toxor schrieb:

    Ja wie gesagt, ich kann mit dem C++ plugin über einen einfachen Button kompilieren, ohne g++ über eine Konsole zu starten, daher weiss ich nicht wie da mehrere headers hinzufügen kann ...

    Hmm.. Dann solltest du dich bei deinem Plugin schlau machen, wie man das macht. Und sonst hald wirklich eine anständige IDE benutzen. Was hast du den für einen Computer, wenn der zu viel Plazt braucht?! 🙄

    0
  • T

    einen kleinen winzigen eee pc ( auf dem xp läuft ), und da habe ich gerade mal 1 gig noch frei, der Mingw braucht knapp 500, also ist mir das deutlich zu viel. Eine anständige IDE braucht zuviel Platz auf dem kleinen 7" Bildschirm, deswegen der vim. Ja ok aber hast schon recht, vermutlich muss ich das plugin mal besser erforschen, danke aufjedenfall an alle die mir hier wertvolle Tips gegeben haben

    0
  • P

    MingW braucht bei mir genau 106,8 MB und ich habe da noch jede Menge Unix-Tools wie ls, rm und so weiter drin, also woher du die Behauptung mit den 500 MB nimmst, weiß ich nicht...

    Ansonsten: Dev-Cpp benutzt doch auch den MingW, wahrscheinlich aber reduziert auf die nötigsten Dateien.

    Und wie du das mit dem Plugin jetzt schaffst, das vernünftig zu kompilieren, musst du in der Dokumentation oder so nachlesen...

    Felix

    0
  • T

    Ach nee sry da hab ich was verwechselt, ich hatte grad cygwin im Kopf (und das braucht sogar fast 1 Gig). Naja ok MinGW wäre dann tatsächlich eine alternative...

    0
Anmelden zum Antworten