richtiger Aufbau

[Nano]

Hallo zusammen ich habe eine wohl recht einfach frage zur richtigen Struktur eines C++ Programmes.

Soweit ich mich informiert habe werden

1.)Methoden im Header deklariert und in der cpp implementiert
2.) Die h Datei in die cpp included

Nun zu meinen Fragen :

Wenn ich nun aus einem anderen Programm funktionen dieser cpp datei aufrufen möchte muss ich die .cpp includen und den header aussen vor lassen ?

Wie sieht es mit Struct und Namespace aus, werden diese im Header deklariert ?

 

[rikola]

Nein, eine .cpp Datei solltest Du nicht mit #include einschliessen.

Wenn Du ein Programm mit g++ (oder einem anderen Compiler) kompilierst, macht der Kompiler eigentlich (min.) zwei Schritte auf einmal fuer Dich:
1) er setzt das, was Du programmiert hast, in Maschinencode um. Das Ergebnis ist eine Objektdatei, meist mit der Endung ".o". Du erhaeltst sie, indem Du statt g++ 'g++ -c' schreibst. In dieser Objektdatei ist tatsaechlich nur das drin, was auch in der .cpp-Datei drinsteht, d.h., Funktionen, die Du aus anderen .cpp-Dateien oder gar Bibliotheken verwendest, sind dort nicht mit drin.

2) er ruft den Linker auf (unter UNIX/Linux oft das Programm ld). Dieser verknuepft alle Funktionen so, dass ein lauffaehiges Programm entsteht.

Wenn Du nun eine Funktion aus einer anderen .cpp Datei verwenden moechtest, dann musst Du diese .cpp-Datei beim Kompilieren mit angeben.

Wenn Du zum Quellcode keinen Zugang hast, benoetigst Du eine Bibliothek (endet unter Linux auf .so, z.B. /usr/lib/libm.so, benoetigt man, um ein "dynamisch verlinktes" Programm zu erzeugen - d.h., zum Ausfuehren benoetigt man nicht nur das Programm, sondern auch diese Bibliothek ) oder ein Archiv (endet unter Linux auf auf .a, z.B. /usr/lib/libm.a, benoetigt man, um ein "statisch verlinktes" Programm zu erzeugen: zum Ausfuehren benoetigt man libm.a dann nicht mehr, weil alles ins Programm gesteckt wurde).

Falls Du den letzten Fall meinst und eine Bibliothek miteinbeziehen moechtest, schreibe das doch kurz, weil es dann eine laengere Hilfestellung gibt.

Ich hoffe, ich habe mehr geholfen als verwirrt!!!

 

[Scorcher24]

Generell sollte man bei Headerdateien schonmal sog. Include-Guards verwenden:

#ifndef __NAMEDERDATEI_H_INCLUDED__
#define __NAMEDERDATEI_H_INCLUDED__

CODE

#endif /* __NAMEDERDATEI_H_INCLUDED__ */

edit: Damit es hier keine Kollisionen mit anderen Dateien gibt, kann man, wenn die Datei soweit fertig ist bzw in einem fortgeschrittenen stadium, auch einen MD5-Hash nehmen. Aber das macht man nur bei Dateien, die es oft gibt, wie setup.h oder so.

Das sorgt dafür, dass du die Datei auch mehrfach einbinden kannst, ohne Linkerfehler. Funktionen, die direkt im Header komplett eingetragen werden, können optimalerweise als "inline" deklariert werden, damit Linkerfehler vermieden werden. Das macht man aber nur für einzeiler.
Diese Headerdatei kannst du dann in jede .cpp einbinden. Und wie schon geschrieben, niemals die .cpp einbinden. Es gibt einzelne Ausnahmen, aber da kommst du selbst drauf irgendwann .

Structs, die in cpp übrigens auch nur Klassen sind, nur by default public statt private, werden im Header deklariert, ausser man möchte sie verstecken oder der User des Headers braucht keinen Zugriff darauf, dann kann man sich auch in der .cpp verstecken:

struct SFoo
{
 int a;
};
// ist das gleiche wie 
class CFoo
{
public: 
   int a;
};

Namespaces braucht man im Header UND in der Source-Datei, wenn man Sie definiert:

// .h 
namespace  MyNamespace
{
   class Foo
  {
     Foo();
  };
}
// .cpp: 
Foo::Foo() {}  //Würde einen Fehler geben
// entweder:
MyNamespace::Foo::Foo() {}
// oder 
namespace MyNamespace 
{
  Foo::Foo() {}
}

HTH
rya.

 

[rikola]

Generell sollte man bei Headerdateien schonmal sog. Include-Guards verwenden:

#ifndef __NAMEDERDATEI_H_INCLUDED__
#define __NAMEDERDATEI_H_INCLUDED__

Mit (doppelteln) fuehrenden Unterstrichen waere ich vorsichtig. Ist zwar "nur" ein Makroname - doch eigentlich sind doppelte Unterstriche fuer Compiler-Interna reserviert, und man ziemlich kranke und kaum vorhersehbare Effekte erreichen, wenn man damit rumspielt (vor einiger Zeit hatte ich mal einen Beispielcode gesehen - leider nun nicht mehr - bei dem eine Ausgabe produziert wurde, bevor das Programm 'main' ueberhaupt erreichte...)