#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 ]

--
If you're posting through Google read <http://cfaj.freeshell. org/google>

[Keith Thompson]

Pedro Graca <he****@dodgeit .com> writes:

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 */
=============== =============== ==========

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[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> :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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]

Keith Thompson wrote:

Pedro Graca <he****@dodgeit .com> writes:

<snip>

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?

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

--
If you're posting through Google read <http://cfaj.freeshell. org/google>

[Pedro Graca]

Richard Heathfield wrote:
[ snip: stuff with references to <stdlib.h> lost ]

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>?

--
If you're posting through Google read <http://cfaj.freeshell. org/google>

[Jordan Abel]

On 2006-01-27, Pedro Graca <he****@dodgeit .com> wrote:

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]

On 2006-01-27, Gregory Pietsch <GK**@flash.net > wrote:

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]

On 2006-01-27, Pedro Graca <he****@dodgeit .com> wrote:

Richard Heathfield wrote:
[ snip: stuff with references to <stdlib.h> lost ]

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]

"Keith Thompson" <ks***@mib.or g> wrote .

Pedro Graca <he****@dodgeit .com> writes:

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.

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(IN VADER *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_an d_take_over_Ear th 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.