Header-Datei was gehört alles rein?

Mögliche Defins sind in der Header auch gut aufgehoben...

Lings wrote:
> Hallo,
>
> was kommt alles in eine Header-Datei rein?

Auf einen kurzen Nenner:
In einem Header File ist alles enthalten, was ein
Verwender der in diesem Modul (Header File + zugehörige
Implementierung) zur Verfügung gestellten Funktionalität
benötigt um diese Funktionalität auch tatsächlich nutzen
zu können.

Das Header File fungiert als 'Interface' zu dieser
Funktionalität.

Wénn deine Funktionalität darin besteht, dass Funktionen
zur Verfügung gestellt werden, dann gehören die Prototypen
der extern sichtbaren Funktionen in das Header File.

Wenn deine Funktionalität bedingt, dass der Verwender
Kenntnis über bestimmte Datenstrukturen braucht, sei es
weil er diese Strukturen befüllen muss oder weil die
Strukturen Teil der Argumentliste von Funktionen ist, dann
gehören diese Strukturdefinitionen ins Header File.

Wenn deine Funktionalität beinhaltet, dass es benannte 'Konstanten',
also C-Makros gibt, die der Verwender deiner Funktionalität kennen
muss (zb. weil es sich dabei um Steuerwerte handelt, mit denen
Funktionen gesteuert werden) dann gehören diese ins Header File.

Wenn deine Funktionalität bedeutet, dass ...... gibt ...... und
dein Verwender dies wissen muss, .... dann gehört ..... ins Header
File.

Alles andere gehört ins C File, in dem auch die Funktionalität
implementiert ist.

Lings wrote:
> dann folgt daraus, dass ich ein Header-Datei erstellen muss, auch wenn
> es nur das Prototyp der Funktion enthält :-D

Muss, im Sinne von 'anderfalls geht die Welt unter' ist übertrieben.
Aber sinnvoll ist es immer.

Nichts und niemand hindert dich daran, sowas hochzuziehen:

File: A.c
*********

1

int foo( void )

2

{

3

  return 0;

4

}

File: B.c
*********

1

int foo( void );

2

3

int main()

4

{

5

  int j = foo();

6

}

Wenn man es genau nimmt, und man ein bischen zocken möchte :-),
kann man sich sogar den Protoypen sparen. Aber das ist dann
in der Realität schon ein Grund dem Programmierer eine in die
Fr... zu hauen.

B.C verwendet eine Funktionalität, die in A.C implementiert ist,
die Funktion foo(). In diesem Beispiel hat sich B.C selbst darum
gekümmert, dass dem Compiler das externe Interface von A.C,
nämlich der Prototyp der Funktion, bekanntgemacht wird.
Aber: Eigentlich ist das nicht die Aufgabe von B.C
Eigentlich ist es die Aufgabe von A.C dem Verwender, nämlich B.C
diese Information zur Verfügung zu stellen. Denn nur A.C kann
letztendlich wissen, ob das so korrekt ist.
Es hindert dich nämlich auch nichts und niemand daran, das hier
zu tun ...

File: B.c
*********

1

double foo( int );

2

3

int main()

4

{

5

  int j = foo( 8 );

6

}

... also falsche Angaben in B.C über die von A.C bereitgestellte
Funktion zu machen.
Das es in diesem Programm krachen wird, dürfte klar sein.

Die Lösung dazu lautet: Header File

File: A.c
*********

1

#include "A.h"

2

3

int foo( void )

4

{

5

  return 0;

6

}

File: A.h
*********

1

#ifndef A_H_INCLUDED

2

#define A_H_INCLUDED

3

4

int foo( void );

5

6

#endif

File: B.c
*********

1

#include "A.h"

2

3

int main()

4

{

5

  int j = foo();

6

}

Wenn du da jetzt denselben Fehler einbaust ....

File: A.h
*********

1

#ifndef A_H_INCLUDED

2

#define A_H_INCLUDED

3

4

double foo( int );

5

6

#endif

.... dann klopft dir der Compiler auf die Finger weil er beim
Compilieren von A.c bemerkt, dass der Protoyp nicht mit der
tatsächlichen Funktionsdefinition übereinstimmt (A.c includiert
ja ebenfalls A.h).

dass