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.
> 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.
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.
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.
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.
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.
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
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.
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
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.
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 ;-)
> 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. ;-)