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.