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
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.
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 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...
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.
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
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 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...
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.
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.
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.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
konflikt.JPG
(78 KB)
