Je travaille avec un système intégré et je suis en train de finir avec une tonne d'interfaçage HW #define macros. Je veux mettre tous ces éléments dans un fichier séparé (pour oop-ness), mais je ne connais pas le meilleur moyen de #include que. Est-ce que je viens de les mettre dans un fichier .C, puis inclure cela? Semble stupide de les mettre dans un fichier .h.
4 Réponses :
Je ne vois rien de mal avec le fichier .h.
Oui, c'est une pratique standard.
Eh bien, la règle générale des prototypes de fonction réside dans les fichiers .h et leurs implémentations dans des fichiers .c. Dans ce cas, je mettais les implémentations dans les fichiers. Ils ne sont normalement pas là où quelqu'un les chercherait.
@Tristan: Ce qui est vrai pour les fonctions n'est pas nécessairement vrai pour les macros; Il est également courant que les fonctions en ligne résident dans les fichiers d'en-tête
@Tristan & Christoph: Il est courant de mettre #define macro dans les fichiers .h. Ces macro sont des fonctions en ligne. Une façon, je donne clairement au lecteur c'est une macro et non une fonction est; Je déclare généralement toutes mes macro en majuscule.
Vous pouvez vérifier le code source de démarrage U, c'est comment ils le font, le mettent dans le fichier .h et c'est vraiment propre de cette façon
Il est généralement préférable de placer les macros d'interfaçage HW dans un fichier d'en-tête réservé au code spécifique à la plate-forme. Cela améliorera votre portabilité, en ce sens que vous pouvez échanger un en-tête pour une plate-forme matérielle pour un en-tête pour une autre plate-forme matérielle à l'aide d'un #define ou d'un paramètre transmis à "faire".
Ceux-ci devraient aller dans les fichiers Le modèle normal est que les fichiers Ainsi, les choses suivantes vont normalement dans Inversement, les choses suivantes vont normalement dans Le cas des "définitions de fonction ne va que dans en C ++, où de nombreuses fonctions sont définies sous forme modélisée et que les définitions doivent donc être incluses chaque fois qu'ils sont utilisées, ces définitions vont très souvent dans le .h . L'autre option est un fichier .c , et cela nécessiterait d'utiliser #include pour inclure un fichier .c , qui confondra très certainement les gens - En plus de confondre votre maquillage, s'il utilise l'hypothèse standard que chaque fichier .c correspondra directement à un fichier compilé .
.h sont destinés aux éléments inclus dans d'autres endroits (et, en particulier dans plusieurs autres endroits), et que .c fichiers sont destinés aux choses qui sont compilées une fois dans des fichiers d'objet.
.h fichiers:
extern Déclarations
.c fichiers:
.c fichiers" est simplement le cas dégénéré lorsque vous n'avez pas de fonctions en ligne.
.h (ou .HPP ou autre) fichier. Donc, ce genre de chose a définitivement précédent.
Je ne recommande pas nécessairement cela, mais que je l'ai vu dans un certain nombre de projets intégrés au cours des 10 dernières années: inclure des fonctions en ligne comme .inl.
Brooks décompose bien les responsabilités. Vous pouvez envisager de séparer les définitions en ligne et macro des prototypes de fonction ordinaires et tels: Votre objectif final est la cohérence: toutes les décisions de mise en page devraient aider ceux qui vous succèdent.
Mettez-les là où vous en avez besoin.
Si vous en avez besoin que pour un fichier, mettez-le en haut de ce fichier.
Si vous en avez besoin pour plusieurs fichiers, mettez-le dans un fichier d'en-tête.
Et si vous ne définissez que dans une seule fonction: à l'intérieur de la fonction ou en haut du fichier?
FWIW: Ce sont appelés "macros", pas "fonctions".
Pourquoi semble-t-il idiot de les mettre dans un fichier .h?
@DMCKEE: Nous pouvons diviser la différence et appelons-leur des "macros en forme de fonction" par opposition à "macros comme des objets" - les termes utilisés dans la norme.