Grundsätzliche Frage zu C (M16C)

Hallo,

Variablen Deklaration
  kommt darauf an wo man sie braucht (im Hauptprogramm, in der 
Funktion).
  Dort deklariert man sie dann.
Constanten
  Ich schreibe die Konstanten, die ich im Library (*.h-Datei) brauche 
ins Library (*.h-Datei) und die Konstanten, die ich im Hauptprogramm 
brauche ins Hauptprogramm (*.c-Datei). Man könnte auch alle ins 
Hauptprogramm schreiben, oder umgekehrt.
Definition von Funktionen
  Ins Library (*.h-Datei)
Programmcode der Funktionen
  Ins Library (*.h-Datei)

MfG
Fabian

Den Programmcode, der in der Funktion abgearbeitet wird, schon.

> Den Programmcode, der in der Funktion abgearbeitet wird, schon.

Nein.

Obwohl man das so pauschaul auch nicht sagen kann. Ist man auf inlining 
aus, muss der Code in den Header.

Aber abgesehen davon

modul.c
*******

1

Alle Funktionen, die das Modul ausmachen

modul.h
*******

1

Alle Variablen und Funktionsprotoypen, die das Modul einem

2

Verwender zur Verfügung stellt.

Ist ganz einfach:
In *.c File kommt die Implementierung. Im Header File wird die 
'Schnittstelle' beschrieben, die ein Verwender des Moduls benötigt, um 
mit dem MOdul zu arbeiten. Das sind im Regelfall die 
Funktionsprototypen, aber auch Strukurdefinitionen, die zb in 
Funktionsaufrufen benutzt werden. IN einzelnen Fällen können dann auch 
noch globale Variablen vorkommen, mit denen man aber eher sparsam sein 
sollte.

OK, dann bin ich eine Ausnahme, die alles in die Header-Datei schreibt 
(ich habs so gelernt).
Aber was macht das für einen Unterschied?

Fabian K. schrieb:
> OK, dann bin ich eine Ausnahme, die alles in die Header-Datei schreibt
> (ich habs so gelernt).
> Aber was macht das für einen Unterschied?

Na dann warten wir mal ab, wenn du den Header in mehreren anderen *.c 
Dateien benutzen willst und dein Linker anmeckert, dass er dieselbe 
Funktionsimplementierung 3 mal vorgefunden hat.

Soweit bin ich noch nicht, dass ich mehrere c-Dateien habe. Bis jetzt 
hab ich genau eine c-Datei fürs Hauptprogramm, der Rest kommt in libs.
Wenn ich mehrere habe, muss ich mich wohl umstellen.

Aber egal, ich glaube Frage wurde jetzt richtig beantwortet.

Fabian K. schrieb:
> Soweit bin ich noch nicht, dass ich mehrere c-Dateien habe.

Dann solltest du vielleicht nicht unbedingt jemanden beratschlagen :-)

> Bis jetzt
> hab ich genau eine c-Datei fürs Hauptprogramm, der Rest kommt in libs.

Du hast ganz sicher keine Libs.
Ein Header-File ist keine Lib :-) Selbst dann nicht, wenn hier im 
µC-Forum so gaten wird, als ob ein abgetrennter Code eine Lib wäre. Aber 
genau genommen ist eine Lib etwas ganz anderes. Wenn du jemals auf 
Desktop Systemen programmierst, wirst du den Unterschied kennen lernen.

Ich programmiere nur in meiner Freizeit uC. Ich bin noch in der 
Ausbildung und dort programmiere ich Desktop-Systeme. Deswegen 
interessiert mich der Unterschied umso mehr?

Eine Library wird so gebaut:

Zuerst wird der Code aufgeteilt. So wie oben

C-File:       Implementierung
Header File:  Schnittstellenbeschreibung

Dann wird das C-File für sich getrennt kompiliert.
Möglicherweise zusammen mit einigen anderen C-Files, die zusammen die 
Library bilden sollen.

Dann nimmt man einen Librarien und bindet all die Object-Files, die man 
vom Compiler für die Einzelteile bekommen hat, zu einer Library 
zusammen.


Dem Kunden, also dem der die Library verwendet, gibt man dann die 
Library selber und die Header Files. In den Header Files finden sich all 
die Beschreibungen und Prototypen wieder, die der Verwender benötigt um 
die Funktionen in der Library aufrufen zu können. Das tut er auch. Er 
compiliert sein Programm und linkt die Library dazu, die dann die 
Implementierungen für die Funktionen liefert.

Vorteil:
* Alle Funktionen sind gemeinsam in einem File, der Library, beisammen. 
Der Verwender muss nur die Lib einlinken und hat alles auf einen Schlag 
verfügbar.
* Der Verwender muss sich nicht mit Compiler Settings rumschlagen, um 
die zugelieferten Funktionen kompilieren zu können. Denn die sind schon 
vorkompiliert in der Library
* Ich kann einem Verwender eine Funktionalität zur Verfügung stellen, 
ohne dass ich ihm den Source Code geben muss. -> Ich kann mein Know-How 
verkaufen, ohne jemanden in meine Karten schauen lassen zu müssen.