include dependecies--best practice?

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

--
Bill Pursell

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

--
Er*********@sun.com

[Bill Pursell]

Eric Sosman wrote:

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

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.

--
Bill Pursell

[Eric Sosman]

Bill Pursell wrote On 08/04/06 16:20,:

Eric Sosman wrote:

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

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

--
Er*********@sun.com

[websnarf]

Bill Pursell wrote:

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Jack Klein]

On 4 Aug 2006 13:20:36 -0700, "Bill Pursell" <bi**********@gmail.com>
wrote in comp.lang.c:

>
Eric Sosman wrote:

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

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 4 Aug 2006 11:51:43 -0700, "Bill Pursell" <bi**********@gmail.com>
wrote in comp.lang.c:

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Simon Biber]

Bill Pursell wrote:

Eric Sosman wrote:

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

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

--
Simon.