Verständnis - C - includes und Prototypen

@MasterFX

Eigentlich ist es eine unfeine Sache die main.h in usart.c
einzubinden.


Seit wann denn das ?

Ich mache das immer so.
Deshalb sinds ja h-Files, damit man sie in c-Files einbinden kann.
Und wenn dabei was schiefgeht, dann ist was im h-File falsch.


Man sollte auch immer das eigene h-File mit einbinden (z.B. uart.h in
uart.c), damit die Typenkonsistenz gewahrt ist. Der Linker macht
nämlich keine Typüberprüfung mehr !


Peter

>> @MasterFX
>>
>> Eigentlich ist es eine unfeine Sache die main.h in usart.c
>> einzubinden.
>
>
> Seit wann denn das ?

Na ja, Ich denke MasterFX siht das genauso wie ich.
'main' als Name ist normalerweise für die Applikation
reserviert. 'usart' ist in diesem Zusammenhang der Name
einer Komponente, die der Applikation zuspielt. Warum
sollte aber eine Komponente wissen in welcher Applikation
sie eingesetzt wird? Wozu braucht uart.c Wissen von
main.h? uart.c/uart.h sollte in sich selbst konsistent
und vollständig sein.
Wenn uart.c Dinge aus avr/io.h braucht, dann soll es diesen
include gefälligst selbst machen und nicht über den Umweg
einer main.h

Es geht also nicht um den #include an sich (daran ist nichts
auszusetzen), sondern ist ein logistisches/organisatorisches
Problem.

> #ifndef _USART_H
> #define _USART_H

Bitte so:

#ifndef USART_H
#define USART_H

Namen, die mit einem Unterstrich beginnen sind (vereinfacht
gesagt) für Compiler und Bibliothek reserviert.

@Karl Heinz

"Wenn uart.c Dinge aus avr/io.h braucht, dann soll es diesen include
gefälligst selbst machen und nicht über den Umweg einer main.h"


So hatte ich auch mal gedacht. Aber dabei kam es regelmäßig zu
Konflikten und Überschneidungen. Besonders, wenn man Programmteile in
neuen Projekten nachnutzen will.

Seitdem mache ich alle Hardwaredefinition (XTAL, Portpins usw.) zentral
in der main.h, kann also dort leicht Änderungen vornehmen, und sehe auch
sofort, ob es zu Konflikten kommt.

Insbesondere wenn man Portpins mehrfach nutzt, ist das Definieren an
einer zentralen Stelle wesentlich übersichtlicher.


Peter

Ich nenne das Teil dann eher defines.h oder project.h, ich glaube,
das löst die Konfusion um den Namen ,main' hier einigermaßen auf.