#include in header file for size_t

[Pedro Graca]

Imagine I have a structure with a size_t member:


/* foo.h */
struct foo {
char const *bar;
size_t barlen;
};
void make_foo(struct foo *p);


Now I #include it where needed


/* foo.c */
#include "foo.h"
void make_foo(struct foo *p) {
p->bar = "immutable string";
p->barlen = 16;
}


If I compile these files now I get a `parse error before "size_t"'.
To compile I need to #include <stdlib.h>.

As foo.c doesn't need anyhting from stdlib.h I thought about including
it in foo.h but then remembered header files shouldn't include other
header files, so I tried including stdlib.h in either file, which worked
for both experiments.

Can this be an exception to the rule about not including header files in
header files?


[ It doesn't matter, but for completeness sake, I'm using gcc 3.3.5 ]
[ compile command-line: gcc -W -Wall -std=c89 -pedantic -c foo.c ]

 

[Keith Thompson]

Imagine I have a structure with a size_t member:


/* foo.h */
struct foo {
char const *bar;
size_t barlen;
};
void make_foo(struct foo *p);


Now I #include it where needed


/* foo.c */
#include "foo.h"
void make_foo(struct foo *p) {
p->bar = "immutable string";
p->barlen = 16;
}


If I compile these files now I get a `parse error before "size_t"'.
To compile I need to #include <stdlib.h>.

As foo.c doesn't need anyhting from stdlib.h I thought about including
it in foo.h but then remembered header files shouldn't include other
header files, so I tried including stdlib.h in either file, which worked
for both experiments.

Can this be an exception to the rule about not including header files in
header files?

Where did you get the idea that there's such a rule?

There's nothing wrong with including header files in header files.
Do it if you need to, don't do it if you don't.

Most (or all?) header files should have include guards so they can
safely be included multiple times. For example:

========================================
#ifndef FOO_H
#define FOO_H

struct foo {
char const *bar;
size_t barlen;
};
void make_foo(struct foo *p);

#endif /* FOO_H */
========================================

 

[Richard Heathfield]

Keith Thompson said:

There's nothing wrong with including header files in header files.
Do it if you need to, don't do it if you don't.

Most (or all?) header files should have include guards so they can
safely be included multiple times. For example:

========================================
#ifndef FOO_H
#define FOO_H

struct foo {
char const *bar;
size_t barlen;
};
void make_foo(struct foo *p);

#endif /* FOO_H */
========================================

You forgot to #include <stddef.h>

 

[Gregory Pietsch]

Most (or all?) header files should have include guards so they can

safely be included multiple times. For example:

Some of them don't: <assert.h>, for one. The only time include guards
shouldn't really be used is if a header can be included multiple times
in the same file and have different effects each time. For example, I
once designed a dynamic array header that I didn't put include guards
in because it needed things defined to work and could be included
multiple times in the same file for dynamic arrays of different types.

Still, it's the exception, not the rule. If an include file should not
have include guards, the programmer should say so in the comments.

Gregory Pietsch

 

[Pedro Graca]

Pedro Graca <[email protected]> writes:

Where did you get the idea that there's such a rule?

I must have misunderstood something I read.
The inexistence of such a rule solves my 'problem'

 

[Pedro Graca]

Richard Heathfield wrote:

You forgot to #include <stddef.h>

Ah! I've peeked into /usr/include/stdlib.h and found out it does a
#include <stddef.h>

My hard disk thanks you

.... or is there another reason to choose <stddef.h> over <stdlib.h>?

 

[Jordan Abel]

Imagine I have a structure with a size_t member:

Now I #include it where needed

If I compile these files now I get a `parse error before "size_t"'.
To compile I need to #include <stdlib.h>.

As foo.c doesn't need anyhting from stdlib.h I thought about including
it in foo.h but then remembered header files shouldn't include other
header files, so I tried including stdlib.h in either file, which worked
for both experiments.

Can this be an exception to the rule about not including header files in
header files?

I've never heard of such a rule, but size_t also "lives" in stddef.h,
which doesn't declare any functions.

 

[Jordan Abel]

The only time include guards shouldn't really be used is if a header
can be included multiple times in the same file and have different
effects each time.

I wouldn't call that a header - i'd maybe name it .inc instead. Same
with includable files that define data structures [unless it has a more
specific suffix associated with it, such as .xpm]

 

[Jordan Abel]

Richard Heathfield wrote:

You forgot to #include <stddef.h>

Ah! I've peeked into /usr/include/stdlib.h and found out it does a
#include <stddef.h>

That's not guaranteed - all that's guaranteed is that size_t (, wchar_t,
and NULL) is made available by both.

My hard disk thanks you

... or is there another reason to choose <stddef.h> over <stdlib.h>?

You don't need the stuff in stdlib.

 

[Malcolm]

Where did you get the idea that there's such a rule?

There's nothing wrong with including header files in header files.
Do it if you need to, don't do it if you don't.

I've never found a good answer to this one.

If you follow a policy of never allowing nested inclusions, then you have a
list of dependencies at the top of each source file.
You also have a list, in reverse order, of the files in call hierarchy.

The problem is that quite often, in video games, you need a "world".
Everything depends on the world, but it also contains everything.
Therefore my function

move_invader(INVADER *baddy, WORLD *wld)

take the world as a parameter, becase the invader needs to update its
position within it.
We will want all the invader functions, like invader_fire, invader_die,
invader_land_and_take_over_Earth in the same invader.c file.

However the world looks like this

typedef struct
{
INVADER *invaderlist;
int width;
int height;
CELL *cells;
SHIP *goody;
} WORLD;

So the easiest thing is to include the definitions of INVADER, CELL, and
SHIP as nested includes in world.h

That means that every file in the program includes "world.h" and no other
headers, and any sense of hierarchy is lost.

 

[Ian Collins]

I've never found a good answer to this one.

If you follow a policy of never allowing nested inclusions, then you have a
list of dependencies at the top of each source file.
You also have a list, in reverse order, of the files in call hierarchy.

The waters are muddied further when the compiler supports some form of
pre-compiled headers, where a global header that includes all headers
can save a significant amount of compile time.

 

[clayne]

That means that every file in the program includes "world.h" and no other
headers, and any sense of hierarchy is lost.

I don't understand what hierarchy has to do with it here. Include when
you need a definition or declaration to be present - otherwise don't.
Perhaps move your globally used types to a world_types.h file or
otherwise equivalent.

You won't get any coding done if you fret about the hierarchy of header
file includes. It doesn't mean make it messy and unorganized - but
there's a point where one just has to move on and start on the actual
heavy lifting. Include-guard everything.

 

[Mark McIntyre]

However the world looks like this

typedef struct
{
INVADER *invaderlist;
int width;
int height;
CELL *cells;
SHIP *goody;
} WORLD;

So the easiest thing is to include the definitions of INVADER, CELL, and
SHIP as nested includes in world.h

I believe that since they're all pointers, you can actually declare
them as incomplete types, and only supply a definition when you need
it.


Mark McIntyre

 

[Mark McIntyre]

I don't understand what hierarchy has to do with it here. Include when
you need a definition or declaration to be present - otherwise don't.

Malcolm's point was that one struct that is universally used, relies
on pointers to other structs which are not always used. Thus his
universal header included all other headers and there was no easy way
to tell what features a given module actually used.

I actually think he can get round this via incomplete types, but its a
valid issue.

Mark McIntyre

 

[Malcolm]

I believe that since they're all pointers, you can actually declare
them as incomplete types, and only supply a definition when you need
it.

That's what I'm currently doing.
I still don't really like it, because then we can't modify WORLD to include
a

struct cell current_cell;

Also, the world.c file itself is still topsy-turvy. Probably the solution is
to put the trivial WORLD functions like "getwidth()" in one file, and the
main ones like "run_for_cycle" in another.