Wie stellt man in C (AtmelStudio7/Atmega) am besten projektweit
Konstanten und einige wenige Variablen zur Verfügung? Also in mehreren
*.c Dateien verfügbar?
Was ist hier gute Programmierstil?
Kommt alles in eine Variablen_Konstanen.h Datei, die dann von allen *.c
Dateien eingebunden wird? Oder muss es eine Variablen_Konstanen.c Datei
sein?
Wie löst ihr solche "Probleme"?
Hierzu helfen mir meine Bücher leider nicht weiter.
Ich schreibe sie als #define in eine Header Datei, die von allen *.c
Dateien eingebunden wird.
Alternativ kannst du die Compiler Option -D (indirekt über die
Projekteinstellungen bzw. im Makefile) benutzen, das wird typischerweise
mit F_CPU gemacht.
Hallo,
die Variablen sollten in einem C-File deklariert werden und dann mittels
extern qualifier über ein H-file bekannt gemacht werden. Konstanten
können als Define in das header file. Falls aus Gründen der qualifier
const verwendet werden muss, verhält es sich wie bei variablen.
Beispiel:
C-File file1.c:
1
unsignedcharfoo=0;
2
unsignedcharbar=0;
H-File file2.h:
1
#define MY_LIMIT 10
2
externunsignedcharfoo;
3
externunsignedcharbar;
C-File file3.c:
1
#include "file2.h"
2
3
voidmyFunc1(void)
4
{
5
foo++;
6
bar++;
7
}
C-File file4.c:
1
#include "file2.h"
2
voidmyFunc2(void)
3
{
4
if(foo>MY_LIMIT)
5
{
6
foo=0;
7
}
8
if(bar>MY_LIMIT)
9
{
10
bar=0;
11
}
12
}
Variablen in Header-Files zu deklarieren ist nicht zu empfehlen, da so
u.U. mehrere Variablen mit dem gleichen Namen erzeugt werden können.
Generell ist von der Verwendung globaler Variablen zu vermeiden.
Gruß
Ich vermute, dass Matthias in seinem Beitrag von (28.12.2018 15:09)
gemeint hat:
Hier soll doch bestimmt file2.c stehen damit es übersichtlich bleibt
- oder?
C-File file1.c:
1
unsignedcharfoo=0;
2
unsignedcharbar=0;
H-File file2.h:
1
#define MY_LIMIT 10
2
externunsignedcharfoo;
3
externunsignedcharbar;
Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?
Mir ist klar, dass ich es mit den globaler Variablen variablen nicht
übertreiben darf. Ich programmiere eine Steuerung für einen Empfänger
mit einem umfangreichem Menü und einem Touchdisplay. Hier ergeben sich
einige Zustände die global verfügbar sein "müssen". Naja, damit das
Projekt nicht zu komplex für mich wird. Mit dem ATMega644 habe ich da
etwa Luft.
Für Anregungen was den guten Programmierstil betrifft bin ich aber
offen.
Joern DK7JB .. schrieb:> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?
Nee.
Es kann zu jeder C Datei ein oder mehrere H Dateien geben.
Es kann eine H Datei in einer, mehreren oder allen C Dateien inkludiert
werden.
Joern DK7JB .. schrieb:> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?
Nein, muss es nicht.
Üblich ist es aber durchaus, dass es zu einem .c-File auch ein (oder
mehrere) .h-file(s) gibt.
Wenn in einem C-File globale Funktionen (nicht static) implementiert
werden, sollten diese in einem gleichnamigen H-File bekannt gemacht
werden. Dies kann dann von den Aufrufenden C-Files eingebunden werden.
Z.B. können für UART init(), put() und get() Funktionen im C-File uart.c
implementiert und über ein H-File uart.h bekannt gemacht werden.
Gruß
Matthias
Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu
haben, wenn es nur ein zugehöriges .c File gibt?
Gibt es hierzu eine sinnvolle Strategie?
Joern DK7JB .. schrieb:> Ihr verwirrt mich etwas.
Ist eigentlich ganz einfach:
Wenn man in einem Programm-Unit, also einer .c Datei irgend etwas
geschrieben hat, worauf andere Programm-Units drauf zugreifen
sollen/können/müssen, also so etwas wie Variablen, Funktionen,
Typdeklarationen usw. - dann schreibt man das in eine "header"-Datei .h,
damit das von anderen Units inkludiert werden kann.
Man kann im Prinzip unendlich viele Headerdateien für seinen Unit
schreiben, die Anzahl ist unbegrenzt. Aber für solchen Firlefanz gibt es
wohl kaum eine praktische Anwendung, da begnügt man sich mit einer
einzigen .h
Ach ja, die Endung .h ist rein willkürlich und nicht festgelegt. Man
könnte im Prinzip das Ganze auch .ottokar nennen - aber wer will sowas
schon?
Merke: beim Programmieren mit C hat man an vielen Stellen völlige
Freiheit - aber eben auch die Freiheit, dabei Bockmist zu verzapfen.
W.S.
Joern DK7JB .. schrieb:> Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu> haben, wenn es nur ein zugehöriges .c File gibt?> Gibt es hierzu eine sinnvolle Strategie?
Eine Strategie könnte zum Beispiel sein, dass ein H-File für den
Globalen Kontext und ein H-File für den Lokalen Kontext verwendet wird.
Im Globalen H-File sind dann Globale Funktionen, Defines, Typen, Enums,
etc. bekannt gemacht, die zur Verwendung der Funktionen benötigt werden.
Im Lokalen H-File sind dann Defines etc. zum Parametrisieren oder
Konfigurieren der Funktionen untergebracht.
Gruß
Joern DK7JB .. schrieb:> Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu> haben, wenn es nur ein zugehöriges .c File gibt?> Gibt es hierzu eine sinnvolle Strategie?
Beispiel: Ein C-File implementiert einen Teil eines Moduls. Nun sollen
z.B. alle Funktionen und verschiedene Typen dem Modul bekannt gemacht
werden, aber nicht dem Benutzer des Moduls, da diese von außen nicht
benutzt werden sollen. Dann macht man einen Header für das Modul und
einen "public"-Header.
PinPon schrieb:> Thomas W. schrieb:>> Konstanten in H Files am besten als #define>> Dann sind es aber keine "Konstanten".> (Hier ist man gerne pingelig.)
Eigentlich können es nur dann Konstanten sein.
Konstanten sind z.B Strings. Oder Werte, von denen Pointer benötigt
werden.
Auch da die extern-deklaration (ohne Initialisierungswert) in eine .h
und mit Initialisierung in .c
Wenn man eine library machen will, dann kommen oft Mini-Funktionen in
eine eigene .c und viele davon zusammen in eine .h schau mal nach abs().
Ist momentan verwirrend aber egal, wird erst später wichtig.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang