.h Datei Problem

[Peter (Gast)]

Hallo,

ich möchte meinen Code aufteilen, habe hier das Problem, dass ich in 
dieser .c Datei dann wieder andere Funktionen benötige wie z.B die 
delay_ms.

Jetzt frage ich mich, wie ich das hinbekomme ?
Zudem wird der Typ uint32_t nicht erkannt.

Ich habe das ganze mal in einen Bilde gegenübergestellt und hoffe, dass 
man mein Problem versteht.

Viele Grüße

Matthias

[Einer K. (Gast)]

Du solltest in die *.h Datei, alle Dateien per include einbinden welche 
du in der *.h brauchst.

Funktionsprototypen müssen nicht extern deklariert werden.
Das sind sie automatisch.

Du solltest in die *.c Datei alle Dateien per include einbinden, welche 
du dort brauchst.

[Daniel (Gast)]

Hallo Matthias,
du musst in deiner .c Datei "stdint.h" und "io.h" einbinden. dann Sollte 
das funktionieren.

Der Compiler versucht deine c-Datei zu kompilieren und benötigt dabei 
diese Infos.


Gruß,
Daniel

[Theor (Gast)]

Also eine direkte Lösung wäre:

Vor dem

#include "timer.h"

noch ein

#include <stdint.h>

zu setzen. Darin sind die Typ-Definitionen für uint32_t (und andere) 
enthalten.

[Dr. Sommer (Gast)]

Theor schrieb:
> Also eine direkte Lösung wäre:

Das ist aber sehr unsauber. Header-Dateien sollten (wie erwähnt) alles 
inkludieren, was sie brauchen. Header-Dateien welche man nicht direkt 
einbinden kann, sondern noch die vorherige Inklusion anderer Header 
erfordern, werden schnell lästig in der Anwendung und bewirken früher 
oder später ein Chaos.
Hierbei muss man sich ggf. mit forward declarations behelfen. Gerade 
gestern bin ich über eine Arduino-Nextion-Library gestolpert, welche 
eine Inklude-Schleife enthält und sich daher überhaupt nicht kompilieren 
lässt...

[Einer K. (Gast)]

Theor schrieb:
> zu setzen. Darin sind die Typ-Definitionen für uint32_t (und andere)
> enthalten.

Da in der timer.h das uint32_t schon im Mako steht, sollte das Include 
auch dahin.

Das ist kein MUSS (da nur ein Makro), aber guter Stil.
Eine sichtbare Abhängigkeit.

[Vincent H. (vinci)]

Dr. Sommer schrieb:
> Theor schrieb:
>> Also eine direkte Lösung wäre:
>
> Das ist aber sehr unsauber. Header-Dateien sollten (wie erwähnt) alles
> inkludieren, was sie brauchen. Header-Dateien welche man nicht direkt
> einbinden kann, sondern noch die vorherige Inklusion anderer Header
> erfordern, werden schnell lästig in der Anwendung und bewirken früher
> oder später ein Chaos.
> Hierbei muss man sich ggf. mit forward declarations behelfen. Gerade
> gestern bin ich über eine Arduino-Nextion-Library gestolpert, welche
> eine Inklude-Schleife enthält und sich daher überhaupt nicht kompilieren
> lässt...

My 2 cents:

clang-format mit SortIncludes = true

Code compiliert nicht? -> strg + a + entf

[Dr. Sommer (Gast)]

Arduino Fanboy D. schrieb:
> Da in der timer.h das uint32_t schon im Mako steht, sollte das Include
> auch dahin.

Sobald man das Makro nutzt, wird es aber gebraucht. Da man durch 
Inklusion sichtbar gemachte Makros auch nutzen können sollte, sollte das 
"#include <stdint.h>" im Header stehen.

[Dr. Sommer (Gast)]

Vincent H. schrieb:
> clang-format mit SortIncludes = true

Das sortiert alphabetisch? Besser wäre noch randomisierte Reihenfolge 
;-)

[Vincent H. (vinci)]

Dr. Sommer schrieb:
> Vincent H. schrieb:
>> clang-format mit SortIncludes = true
>
> Das sortiert alphabetisch? Besser wäre noch randomisierte Reihenfolge
> ;-)

Via regex lassen sich verschiedene Include-Kategorien einstellen. Mit 
ein wenig regex-magic kann ma da vielleicht was randomisieren. :D

Das würde aber meiner Zwangsordnungsstörung dann auch nicht gut tun, 
wenn der Header fürs h/c Päärchen nicht an erster Stelle käme...

[W.S. (Gast)]

Peter schrieb:
> ich möchte meinen Code aufteilen..

Ja dann tue dieses - aber tu es mit Verstand.

Wozu also sollen diese zwei #define's in der .h gut sein?

So etwas gehört in die zugehörige .c hinein, damit Interna dieses Moduls 
nicht in alle anderen Moduln breitgetreten werden.

Dann brauchst du auch nicht dieses uint_sonstwas in deiner .h Datei.

Theor schrieb:
> Also eine direkte Lösung wäre:
>
> Vor dem
> #include "timer.h"
>
> noch ein
> #include <stdint.h>

Genau DAS ist die richtige Herangehensweise. Allerdings ist das alles im 
konkreten Fall herzlich überflüssig.

Dr. Sommer schrieb:
> Das ist aber sehr unsauber. Header-Dateien sollten (wie erwähnt) alles
> inkludieren, was sie brauchen.

Das ist in den allermeisten Fällen falsch. Man handelt sich damit nur 
einen nicht enden wollenden Rattenschwanz von unnützen Definitionen und 
dergleichen ein. Richtig sind hingegen folgende zwei Leitsätze:

1. in eine .h Datei gehört nur solches Zeug hinein, was die aufrufenden 
Programmteile wirklich benötigen. Nicht jedoch internes Zeug der 
zugehörigen .c Datei. Das soll in dieser Datei bleiben und nicht in alle 
anderen Dateien breitgetreten werden.

2. in eine .h Datei gehört normalerweise kein Inkludieren anderer .h 
Dateien hinein. So etwas soll man tunlichst bleiben lassen und nur tun, 
wenn wirklich absolut dringende Gründe vorliegen. Aber alles, was nur 
Gewohnheit ist, gehört nicht dazu.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Das ist in den allermeisten Fällen falsch. Man handelt sich damit nur
> einen nicht enden wollenden Rattenschwanz von unnützen Definitionen und
> dergleichen ein.

Wieso ist eine Definition unnütz, wenn der Header sie braucht? Und was 
schadet es, viele Header einzubinden? Definitiv weniger, als Zeit damit 
zu verschwenden, die richtige Reihenfolge zum Inkludieren der Header 
auszutüfteln. Wenn man die stdint.h sowieso inkludieren muss, was bringt 
es das in der .c Datei zu tun? Da doch lieber im Header, dann kann man 
es in den sie nutzenden .c-Dateien nicht vergessen.

W.S. schrieb:
> 2. in eine .h Datei gehört normalerweise kein Inkludieren anderer .h
> Dateien hinein.

Das macht sogar die C Standard Library. Kann also nicht so falsch sein. 
Wäre doch blöd, wenn man string.h nicht inkludieren könnte, ohne vorher 
stddef.h zu inkludieren, weil darin size_t definiert ist. So unnütz ist 
die stddef.h also nicht.

[Dr. Sommer (Gast)]

W.S. schrieb:
> So etwas gehört in die zugehörige .c hinein, damit Interna dieses Moduls
> nicht in alle anderen Moduln breitgetreten werden.

Keiner hat gesagt, dass das Interna sind. Vielleicht gehört es zum 
Interface.