Sinn von Header Files im CCS?

[S. K. (mamelmuck)]

Hallo,

ist das Header-Konzept im CCS 3.1 überflüssig?

Eigentlich schreibt man doch in seine nötigen Zusatz C-Files die eigene 
Include Anweisung an den Anfang und in jedes andere File was den Inhalt 
dieses Zusatz C-Files benötigt auch. Wenn irgendwo was fehlt meckert der 
Compiler, logisch bis jetzt ;-)

Momentan bin ich im CCS-Projekt aber das Main-File und zwei betreffende 
Zusatz C-Dateien ein und gebe nirgends ein Include an und es 
funktioniert!

Da dürfte doch eigentlich nicht sein oder? Was läuft da falsch, wenn es 
so läuft hätte das Header-Konzept keinen Sinn mehr!

Also in der Main werden Funktionen aus der Zusatz1.c verwendet und und 
der Zusatz2.c Funktionen aus der Zusatz1.c. Einbinden ins Projekt 
(Source) reicht zu und es funktioniert.

[Rufus Τ. F. (rufus)]

> Momentan bin ich im CCS-Projekt aber das Main-File und zwei betreffende
> Zusatz C-Dateien ein und gebe nirgends ein Include an und es
> funktioniert!

Du schreibst dann offensichtlich sowas wie

  #include "blafusel.c"

Das funktioniert zwar, ist aber Murks.

[S. K. (mamelmuck)]

Nein, ganz bestimmt nicht :-) eher sowas

#include "dsp_HVquell_rs232.h"

Ich binde die zwei C-Files nur über das Fenster "File-View" in das 
Verzeichnis "Source" mittels "Add Files to Project" ein.

[S. K. (mamelmuck)]

Ich habe gerade noch einmal etwas anderes probiert. Ob der Compiler 
wenigstens stolpert, wenn man keine Funktionsprototypen deklariert und 
die Funktionen in dem betreffenden File so anordnet das in der ersten 
Funktion eine, erst weiter unten aufgeführte, aufgerufen wird.

Hier ist alles normal, der Compiler meckert das er die Funktion nicht 
kennt! Deklaration geschrieben oder eigenen Header eingebunden, und es 
funktioniert wieder.

Aber warum findet der Compiler die einzelnen Funktionen in den anderen 
eingebundenen C-Files ohne irgendwelche Deklarationen, ist doch kurios!

Ich habe auch schon versucht die Reihenfolge der Compilierung der 
einzelnen Dateien zu ändern, alle Objekt-Dateien werden anstandslos 
erzeugt und dann zum Programm gelinkt. Und laufen tut das Programm auch.

[Rufus Τ. F. (rufus)]

Moment.

Du bindest in Dein main-File die Headerdateien der beiden 
"Zusatz"-Dateien ein, nur nicht die in diese selbst?

Das hattest Du anfänglich etwas anders ausgedrückt
"und gebe nirgends ein Include an".

So aber wird das hier daraus:

main.c:

  #include "a.h"
  #include "b.h"

aber

a.c und b.c:

  kein #include "a.h" bzw. b.h"?


Das ist auch nicht zwingend erforderlich, aber ratsam.

Ratsam nämlich, weil dann nämlich Unterschiede zwischen Deklaration 
(Funktionsprototyp in der Headerdatei) und Definition (Funktion selbst 
im C-Sourcecode) vom Compiler erkannt werden können, was beim weglassen 
des #includes nicht der Fall ist.

Und oft ist es auch nötig, wenn beispielsweise eine Struktur, ein enum 
oder irgendwelche #defines sowohl in a.c als auch im main.c verwendet 
werden sollen.

[S. K. (mamelmuck)]

Ne, :-) ich muss es noch einmal erklären, also:

main.c

#include "a.h"
#inlcude "b.h"

void main(void)
{
funktion_a();
...
funktion_b();
...
}

a.c

#include "a.h"
#include "b.h"

void funktion_a(void)
{
funktion_b();
...
}

b.c

#inlcude "b.h"

funktion_b()
{
...
}

So wäre es doch richtig oder? :) Es geht aber auch komischer weise so:

main.c

void main(void)
{
funktion_a();
...
funktion_b();
...
}

a.c

void funktion_a(void)
{
funktion_b();
...
}

b.c

funktion_b()
{
...
}

Im Projektverzeichnis steht nur:
main.c
a.c
b.c

[Rufus Τ. F. (rufus)]

Funktionieren tut das schon, allerdings sollte der Compiler beim 
Übersetzen von main.c Warnungen ausspucken, daß ihm die 
Funktionsprototypen von funktion_a und funktion_b nicht bekannt sind.

Dasselbe sollte beim Übersetzen von a.c geschehen, da dort funktion_b 
aufgerufen wird.

Tut er das nicht, liegt entweder ein Konfigurationsproblem vor 
(Compilerwarungen abgeschaltet?) oder der Compiler ist ... Schrott.

[Benedikt K. (benedikt)]

Rufus t. Firefly schrieb:
> Funktionieren tut das schon, allerdings sollte der Compiler beim
> Übersetzen von main.c Warnungen ausspucken, daß ihm die
> Funktionsprototypen von funktion_a und funktion_b nicht bekannt sind.

Und diese Warnungen sollte man ernst nehmen, denn dann geht der Compiler 
meist davon aus, dass er alle eventuell übergebenen Werte als int 
übergeben soll (da er es ja nicht besser). Das kann dann böse Fehler 
ergeben wenn anstelle eines long nur ein int übergeben wird oder 
ähnliches.

[mamelmuck (Gast)]

Ich weis, aber keine Warnungen, Programm funktioniert. Ich hab schon die 
Namen der betreffenden Funktionen geändert falls sich Speicher noch 
irgendwas befinden sollte.

Compiler Parameter:
-g -fr"$(Proj_dir)\Debug" -i"$(Proj_dir)\include" -d"_DEBUG" 
-d"LARGE_MODEL" -ml -v28

CCS 3.1 von TI

[Rufus Τ. F. (rufus)]

Dann müsste sich main.c auch übersetzen lassen, wenn darin eine Funktion 
aufgerufen wird, die nirgendwo definiert ist.

Probier das mal aus.

Der Linker wirft dann natürlich das Handtuch.

[S. K. (mamelmuck)]

HeHe,
meine neue Funktion

logisch();

 kennt er natürlich nicht.

Wie schon gesagt das Umstellen von Funktionen innerhalb einer C-Datei 
ohne Deklaration macht dem Compiler zu schaffen, hier weiß er auf einmal 
nicht mehr wo sie zu finden ist.

Gibt es vielleicht eine "interne" Reihenfolge wie das CCS die Dateien 
dem Compiler vorgibt? Wenn der Compiler die richtige Reihenfolge bekommt 
... obwohl ne der Gedanke is och schrott. Der Compiler compiliert ja a.c 
und b.c allein. grübel

[A.Nonym (Gast)]

Mach doch mal ein "make clean", wenn das in diesem Programm geht. Ich 
meine alle .o und sonstige Zwischenprodukte löschen.
Den Effekt beobachte ich manchmal, wenn ich im Code herumpfusche, die 
Dateien aber auf Grund falscher Abhängigkeiten nicht neu übersetzt 
werden.

[gast (Gast)]

was bitte ist CCS?

ohne das zu wissen, trotzdem ein beitrag von mir zum thema:
ich hatte mal in einer lehrveranstaltung (dsp-programmierung) eine ide 
(weiß den namen/hersteller des ganzen nicht mehr), bei der man auch 
einfach c-dateien zu einem projekt hinzufügen konnte. aus den c-dateien 
wurden dann header erstellt und das ganze dann irgendwie automatisch 
inkludiert.

ich habe das gehasst, weil ich am anfang öfter den überblick verloren 
habe was da abläuft bis ich die richtige option gefunden habe, um den 
schrott abzustellen ;-)

[A.Nonym (Gast)]

CCS ist Code Composer Studio. Die Entwicklungsumgebung die bevorzugt bei 
TI-Produkten zum Einsatz kommt.

[S. K. (mamelmuck)]

> Mach doch mal ein "make clean", wenn das in diesem Programm geht. Ich
> meine alle .o und sonstige Zwischenprodukte löschen.
> Den Effekt beobachte ich manchmal, wenn ich im Code herumpfusche, die
> Dateien aber auf Grund falscher Abhängigkeiten nicht neu übersetzt
> werden.

Hatte ich schon probiert, alles außer C-Files gelöscht. Ich probier mal 
das Clean Build, leider auch "kein" Erfolg.

Arbeite jetzt an einem anderen System und in einer VM. Gleiches 
Ergebnis. Vielleicht sollte ich sagen das ich in den Jahren schon oft 
solche Dinge erlebt, endeckt oder selbst "produziert" habe. Ich scheine 
das irgendwie magisch anzuziehen.
Keine Bange, das Phänomen ist nicht auf C beschränkt. ;-)