include dependecies--best practice?

B

Bill Pursell

I read recently (can't remember if it was on this
group or elsewhere) that it is a bad idea to write
a header file this way:

#ifndef FOO_HDR
#define FOO_HDR 1

#include <stdio.h>

int foo(FILE *i);
#endif

Instead, one should not rely on the header guards
in the included library and require that the program
that includes foo.h include stdio.h first.

Is that true? If so, why?
 
E

Eric Sosman

Bill Pursell wrote On 08/04/06 14:51,:
I read recently (can't remember if it was on this
group or elsewhere) that it is a bad idea to write
a header file this way:

#ifndef FOO_HDR
#define FOO_HDR 1

#include <stdio.h>

int foo(FILE *i);
#endif

Instead, one should not rely on the header guards
in the included library and require that the program
that includes foo.h include stdio.h first.

Is that true? If so, why?

This is Question 10.7 in the comp.lang.c Frequently
Asked Questions (FAQ) list

http://www.c-faq.com/
 
B

Bill Pursell

Eric said:
Bill Pursell wrote On 08/04/06 14:51,:

This is Question 10.7 in the comp.lang.c Frequently
Asked Questions (FAQ) list

Unfortunately, the FAQ doesn't really answer the question
other than to say it's a stylistic question. However, it
did make me realize that it was in the Indian Hill Style
guide that I'd read the opinion that it was a bad idea
to include the necessary headers, as it relies on
the headers being properly guarded. However,
the Indian Hill style guide is now 16 years old...
is there a more definitive answer? (ie, can the FAQ
be updated to say: "Go ahead and include what you
need: current implementations have the proper
header guards in place.")

My choice is to include everything you need. I'd
love to hear the reasons of people who think that's
a bad idea.
 
E

Eric Sosman

Bill Pursell wrote On 08/04/06 16:20,:
Eric said:
Bill Pursell wrote On 08/04/06 14:51,:


This is Question 10.7 in the comp.lang.c Frequently
Asked Questions (FAQ) list


Unfortunately, the FAQ doesn't really answer the question
other than to say it's a stylistic question. [...]

It does a bit more than that: It also lays out the
principal arguments on each side.
My choice is to include everything you need. I'd
love to hear the reasons of people who think that's
a bad idea.

If you've got a new argument (for or against), by all
means arise it and let's have a discussion. But if you
just want to hear the same old arguments re-orated for your
amusement, ... I fear you'll probably get your wish.

"LESS FILLING!!"

"TASTES GREAT!!!"
 
W

websnarf

Bill said:
I read recently (can't remember if it was on this
group or elsewhere) that it is a bad idea to write
a header file this way:

#ifndef FOO_HDR
#define FOO_HDR 1

#include <stdio.h>

int foo(FILE *i);
#endif

I don't understand, at all, how one could possibly object to this.
There is an obvious plus for doing this: it allows libraries to have
interdependencies in their interface without the programmer having to
account for these in their list of #includes.

So an obvious example -- lets say the whole API of module A depends on
typedefs from module B. Now in your mainline code you need just A, but
not the parts of the API which use tye typedefs from B. Intuitively
you decide you just want to include A's include file. Now if the A
include file did not also intrinsically include the B file then you
would be *forced* to include the B include file in your mainline code
*before* including the A include file. So the mainline code is now
including a file, even though you might find no direct usage of any of
its contents inside your mainline code.

Using this header guarding trick basically allows you to always declare
dependencies on a file by file basis and to avoid *hidden* dependencies
such as "include file order" dependencies. Unfortunately it allows you
to abuse "implicit dependencies" (relying on the fact that another
module will automatically include some other include file for you, so
that you can avoid including it yourself) but those usually make
themselves clear very easily as dependencies change and usually don't
result in any severe negative impact.

If that's not convincing enough for you, go look at the include files
from your compiler. Every compiler I have access to uses precisely
this sort of trick in their include files.
Instead, one should not rely on the header guards
in the included library and require that the program
that includes foo.h include stdio.h first.

Is that true? If so, why?

I don't see how it could possible be true.
 
J

Jack Klein

Unfortunately, the FAQ doesn't really answer the question
other than to say it's a stylistic question. However, it
did make me realize that it was in the Indian Hill Style
guide that I'd read the opinion that it was a bad idea
to include the necessary headers, as it relies on
the headers being properly guarded. However,
the Indian Hill style guide is now 16 years old...
is there a more definitive answer? (ie, can the FAQ
be updated to say: "Go ahead and include what you
need: current implementations have the proper
header guards in place.")

Frankly, I thought the Indian Hills style guide was pretty bad when it
was new.
 
J

Jack Klein

I read recently (can't remember if it was on this
group or elsewhere) that it is a bad idea to write
a header file this way:

#ifndef FOO_HDR
#define FOO_HDR 1

#include <stdio.h>

int foo(FILE *i);
#endif

Instead, one should not rely on the header guards
in the included library and require that the program
that includes foo.h include stdio.h first.

Is that true? If so, why?

Best practice for whom, and under what circumstances?

We work on embedded systems in C, some of them fairly large for
embedded systems in C, and most of them safety critical. We have
coding rules over which I have the greatest input.

One of the first is that every included file has an include guard.
Period.

The second is that every include file we write must pass the empty.c
test:

#include "include_file_to_test.h"

....must compile without errors or warnings. The only exception is an
include file which contains macros and type definitions only. Then
you might have to add "extern int x;" to empty.c to avoid the
warning/error that some compilers generate because every translation
unit in C is supposed to contain at least one external declaration.
 
S

Simon Biber

Bill said:
Unfortunately, the FAQ doesn't really answer the question
other than to say it's a stylistic question. However, it
did make me realize that it was in the Indian Hill Style
guide that I'd read the opinion that it was a bad idea
to include the necessary headers, as it relies on
the headers being properly guarded. However,
the Indian Hill style guide is now 16 years old...
is there a more definitive answer? (ie, can the FAQ
be updated to say: "Go ahead and include what you
need: current implementations have the proper
header guards in place.")

The standard requires behaviour equivalent to that achieved with header
guards. That is, including a standard header more than once in a
translation unit has no ill effect. (The exception is <assert.h> of
course, which can change the behaviour of the assert macro each time it
is included.)

The implementation may not use actual header files but simulate them
internally. Equally, it may not use the #ifndef #define #endif idiom but
some non-standard double-inclusion avoidance feature ('pragma once'
comes to mind).
My choice is to include everything you need. I'd
love to hear the reasons of people who think that's
a bad idea.

That's my choice too.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top