Anfängerfrage C, Konstanten projektweit zur Verfügung stellen

[Joern DK7JB .. (moin)]

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.

[Thomas W. (diddl)]

Konstanten in H Files am besten als #define


Globale Variable in einem H File als "extern … …" und dann in EINEM C 
File definieren.

[Stefan ⛄ F. (stefanus)]

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.

[Matthias (Gast)]

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:

unsigned char foo = 0;
unsigned char bar = 0;

H-File file2.h:

#define MY_LIMIT   10
extern unsigned char foo;
extern unsigned char bar;

C-File file3.c:

#include "file2.h"

void myFunc1(void)
{
   foo++;
   bar++;
}

C-File file4.c:

#include "file2.h"
void myFunc2(void)
{
   if(foo > MY_LIMIT)
   {
      foo = 0;
   }
   if(bar > MY_LIMIT)
   {
      bar = 0;
   }
}

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ß

[Stefan ⛄ F. (stefanus)]

Hat er nicht nach Konstanten gefragt?

Bei meinem Liebling, dem ATtiny13A feilsche ich (zwangsläufig) um jedes 
Byte RAM.

[Stefan ⛄ F. (stefanus)]

Ach so, hab ich übersehen. Na dann ergänzen sich ja unsere beiden 
Beiträge prima.

[Joern DK7JB .. (moin)]

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:

unsigned char foo = 0;
unsigned char bar = 0;

H-File file2.h:

#define MY_LIMIT   10
extern unsigned char foo;
extern unsigned char bar;

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.

[Arduino Fanboy D. (ufuf)]

Joern DK7JB .. schrieb:
> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?

Nöö.

[Thomas W. (diddl)]

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.

[Matthias (Gast)]

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

[Joern DK7JB .. (moin)]

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?

[W.S. (Gast)]

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.

[Matthias (Gast)]

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ß

[PinPon (Gast)]

Thomas W. schrieb:
> Konstanten in H Files am besten als #define

Dann sind es aber keine "Konstanten".
(Hier ist man gerne pingelig.)

[Rolf M. (rmagnus)]

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.

[A. S. (achs)]

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.