Ich arbeite mit einem eingebetteten System, und ich bin am Ende mit einer Tonne von HW-Schnittstellen #define Makros. Ich möchte alle diese in eine separate Datei (für OOP-Ness), aber ich weiß nicht, der beste Weg zu #include dass. Bringe ich sie alle in eine .c-Datei und schließe sie dann ein? Scheint albern, diese in eine .h-Datei zu legen.Wo stelle ich all diese funktionsähnlichen #defines in C?
Ich sehe nichts falsch mit der .h-Datei.
Ja, das ist Standard. – caf
Nun, die allgemeine Faustregel lautet: Funktionsprototypen befinden sich in .h-Dateien und ihre Implementierungen in .c-Dateien. In diesem Fall würde ich die Implementierungen in die .h-Dateien einfügen - normalerweise nicht dort, wo jemand nach ihnen suchen würde. – Tristan
@Tristan: Was für Funktionen gilt, gilt nicht unbedingt für Makros; es ist auch üblich, dass Inline-Funktionen in Header-Dateien gespeichert werden – Christoph
Diese sollten in den .h Dateien gehen. Die andere Option ist eine .c Datei, und das würde die Verwendung #include erfordern, um eine .c Datei einzuschließen, die Leute auf jeden Fall verwirren wird - sowie Ihr Makefile verwirrend, wenn es die Standardannahme verwendet, die jede .c Datei direkt a entspricht kompiliert .o Datei.
Das normale Muster ist, dass .h Dateien für Dinge sind, die an anderen Orten (und insbesondere an mehreren anderen Orten) enthalten sind, und dass .c Dateien für Dinge sind, die einmal in Objektdateien kompiliert werden.
Somit sind die folgenden Dinge normalerweise in .h Dateien gehen:
extern ErklärungenUmgekehrt sind die folgenden Dinge normalerweise in .c Dateien gehen:
Der Fall " Funktionsdefinitionen gehen nur in .c Dateien "ist einfach der degenerierte Fall, wenn Sie keine Inline-Funktionen haben.
In C++, wo viele Funktionen in Vorlagenform definiert sind und daher die Definitionen bei ihrer Verwendung enthalten sein müssen, gehen diese Definitionen sehr oft in die Datei .h (oder .hpp, oder was auch immer). Diese Art von Dingen hat definitiv einen Präzedenzfall.
Ich empfehle das nicht unbedingt, aber habe es in den letzten 10 Jahren in einigen eingebetteten Projekten gesehen: Inline-Funktionen wie .inl.
Brooks gliedert die Verantwortlichkeiten gut aus. Sie sollten erwägen Inline- und Makrodefinitionen der gewöhnlichen Funktionsprototypen zu trennen und so:
#include "prototypes.h"
#include "macros.inl"
int foo(void);
int bar(char);
Ihr Endziel ist die Konsistenz: alle Layouts Entscheidungen diejenigen, die Sie zum Erfolg unterstützen sollten.
Legen Sie sie dort hin, wo Sie sie brauchen.
Wenn Sie es nur für eine Datei benötigen, dann legen Sie es an der Spitze dieser Datei.
Wenn Sie es für mehrere Dateien benötigen, dann legen Sie es in eine Header-Datei.
FWIW: Diese werden "Makros", nicht "Funktionen" genannt. – dmckee
Warum scheint es albern, sie alle in eine .h-Datei zu setzen? – FrustratedWithFormsDesigner
@dmckee: Wir können den Unterschied aufteilen und sie "funktionsähnliche Makros" nennen, im Gegensatz zu "objektartigen Makros" - den im Standard verwendeten Begriffen. –