Devrait structurer les définitions.h ou.c fichier?
j'ai vu à la fois les définitions complètes de struct dans les en-têtes et les simples déclarations-y a-t-il un avantage à une méthode par rapport à l'autre?
si cela fait une différence, j'ai généralement tapé une structure comme ça dans le .h
typedef struct s s_t;
Modifier
pour être clair, les options sont déclaration dans le fichier d'en-tête et définition dans la classe, ou à la fois déclaration et définition dans l'en-tête fichier. Les deux devraient donner la même facilité d'utilisation, même si on est par liaison, ne devraient-ils pas?
je vois beaucoup de doubles, par exemple ici mais pas de correspondance exacte. S'il vous plaît, corrigez-moi si je me trompe à cet égard.
6 réponses
structures Privées pour ce fichier devrait aller dans le .fichier c, avec une déclaration dans le .h si elles sont utilisées par une fonction dans le fichier .h.
structures Publiques devrait aller dans le .h fichier.
les deux devraient donner la même utilisabilité, même si on est par liaison, ne devraient-ils pas?
non, pas si vous considérez autre chose .C y compris le même en-tête. Si la définition de la structure n'est pas visible par le compilateur, les détails de cette définition ne peuvent pas être utilisés. Une déclaration sans définition (par exemple juste struct s; ) provoque l'échec du compilateur si quelque chose essaie de regarder à l'intérieur de struct s , alors qu'encore lui permettre par exemple de compiler struct s *foo; (aussi longtemps que foo n'est pas plus tard déréférencé).
comparez ces versions de api.h et api.c :
Definition in header: Definition in implementation:
+---------------------------------+ +---------------------------------+
| struct s { | | struct s; |
| int internal; | | |
| int other_stuff; | | extern void |
| }; | | api_func(struct s *foo, int x); |
| | +---------------------------------+
| extern void | +---------------------------------+
| api_func(struct s *foo, int x); | | #include "api.h" |
+---------------------------------+ | |
+---------------------------------+ | struct s { |
| #include "api.h" | | int internal; |
| | | int other_stuff; |
| void | | }; |
| api_func(struct s *foo, int x) | | |
| { | | void |
| foo->internal = x; | | api_func(struct s *foo, int x) |
| } | | { |
+---------------------------------+ | foo->internal = x; |
| } |
+---------------------------------+
ce client de L'API fonctionne avec l'une ou l'autre des versions:
#include "api.h"
void good(struct s *foo)
{
api_func(foo, 123);
}
celui-ci s'agite dans les détails de la mise en œuvre:
#include "api.h"
void bad(struct s *foo)
{
foo->internal = 123;
}
qui fonctionnera avec la version" definition in header", mais pas avec le "definition in implementation" version, comme dans ce dernier cas le compilateur n'a aucune visibilité de la disposition de la structure:
$ gcc -Wall -c bad.c
bad.c: In function 'bad':
bad.c:5: error: dereferencing pointer to incomplete type
$
ainsi, la version" definition in implementation " protège contre l'abus accidentel ou délibéré des détails de mise en œuvre privée.
si la structure doit être utilisée par d'autres unités de compilation (.c files), placez-le dans le fichier d'en-tête afin que vous puissiez inclure ce fichier d'en-tête partout où il est nécessaire.
si la structure n'est utilisée que dans une seule unité de compilation (.C file), vous le placez dans cela .c fichier.
Le point est, de le placer dans un fichier d'en-tête vous permet d'utiliser la structure (ou toute autre définition) à partir de plusieurs fichiers source, juste en-tête de fichier.
mais si vous êtes sûr qu'il ne sera utilisé qu'à partir d'un seul fichier source, alors il ne fait vraiment aucune différence.
je les ai mis dans le fichier C pour le rendre plus Orienté Objet, voir cet article .
en général, je ne pense pas que cela fasse une énorme différence si vous les mettez dans les fichiers d'en-tête ou de source. Toutefois, si vous avez besoin d'accéder aux membres d'une structure à partir de plusieurs fichiers source, il est plus facile de mettre la structure dans un fichier d'en-tête et d'inclure d'autres fichiers, où la structure est nécessaire.