Should struct definitions go in .h or .c file?

I've seen both full definitions of structs in headers and just declarations—is there any advantage to one method over the other?

If it makes a difference, I usually typedef a struct like so in the .h

typedef struct s s_t;

To be clear, the options are declaration in the header file and definition in the class, or both declaration and definition in the header file. Both should result in the same usability, even if one is by linkage, shouldn't they?


I see many almost duplicates, e.g. here but no exact matches. Please correct me if I'm wrong in this regard.

116810 次浏览

I put them into the C file to make it more Object Oriented, see this article.

The point is, placing it in a header file allows you to use the structure (or any other definition) from multiple source files, just by including that header file.

But if you are sure it will only be used from one source file, then it really doesn't make any difference.

If the struct is to be used by other compilation units (.c files) , place it in the header file so you can include that header file wherever it is needed.

If the struct is only used in one compilation unit (.c file), you place it in that .c file.

Private structures for that file should go in the .c file, with a declaration in the .h file if they are used by any functions in the .h .

Public structures should go in the .h file.

Both should result in the same usability, even if one is by linkage, shouldn't they?

No, not when you consider other .c files including the same header. If the definition of the structure is not visible to the compiler, the details of that definition cannot be used. A declaration without a definition (e.g. just struct s;) causes the compiler to fail if anything tries to look inside struct s, while still allowing it to e.g. compile struct s *foo; (as long as foo is not later dereferenced).

Compare these versions of api.h and 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;          |
| }                               |
+---------------------------------+

This client of the API works with either version:

#include "api.h"


void good(struct s *foo)
{
api_func(foo, 123);
}

This one pokes around in the implementation details:

#include "api.h"


void bad(struct s *foo)
{
foo->internal = 123;
}

which will work with the "definition in header" version, but not with the "definition in implementation" version, as in the latter case the compiler has no visibility of the layout of the structure:

$ gcc -Wall -c bad.c
bad.c: In function 'bad':
bad.c:5: error: dereferencing pointer to incomplete type
$

So, the "definition in implementation" version protects against accidental or deliberate misuse of private implementation details.