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

[Ian Collins]

Malcolm wrote:

"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 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.

--
Ian Collins.

[clayne]

Malcolm wrote:

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]

On Sat, 28 Jan 2006 00:55:14 +0000 (UTC), in comp.lang.c , "Malcolm"
<re*******@btin ternet.com> wrote:

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
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 27 Jan 2006 20:19:24 -0800, in comp.lang.c , "clayne"
<cl****@anodize d.com> wrote:

Malcolm wrote:

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.

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
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Malcolm]

"Mark McIntyre" <ma**********@s pamcop.net> wrote

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.

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_cy cle" in another.