.h Datei Problem

Gast #5645887
Lesenswert?

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
Angehängte Dateien:
Gast #5645895
Lesenswert?

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.
Gast #5645897
Lesenswert?

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
Gast #5645940
Lesenswert?

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...
Gast #5645941
Lesenswert?

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.
#5645945
Lesenswert?

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
#5645956
Lesenswert?

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...
Gast #5646315
Lesenswert?

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.
Gast #5646332
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren