Header files question

[mdh]

Well, K& R has finally gotten to header files!!!

May I ask this. (Have checked out the FAQ)

I am using "Xcode" to compile the program, so it may well be that this
is doing something strange.

What is unique to a header file?

For example, if I define an integer thus:

i=96;

can I use i in, for example main.c without first declaring it (using
extern i), and if so, what makes the header file diffferent from say,
"other_file.c" with the same definition?

Thanks in advance.

 

[mdh]

I meant "int i=96;

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

I meant "int i=96;

Little. It is very much like if you had placed everything in the code
in your .c file instead of saying #include "myheader.h"


Nothing. If you include a header file with a definition in more than
one .c file, you get mutiple definition - which you don't want.
Define it in exactly one of your .c files, and if you need to
make it available to other .c files, you can e.g. place a
declaration (use the extern keyword) in a header file which
you include where needed.

 

[mdh]

Little. It is very much like if you had placed everything in the code
in your .c file instead of saying #include "myheader.h"

Nothing. ............... place a declaration (use the extern keyword) in a header file which
you include where needed.

So Nils, what you are saying? is
Declarations in the header file?
Definitions in other_c_files?

So, is the designation ".h" simply "convenience" if you have a massive
program, it makes it easier debugging etc or if multiple people are
working on it? From what you say, you could put all declarations in
say, "my_specialfile.c", use # include where necessary, but it would
not be as clear?

Thanks

 

[CBFalconer]

Nils O. Selåsdal wrote:
.... snip ...

So Nils, what you are saying? is
Declarations in the header file?
Definitions in other_c_files?

So, is the designation ".h" simply "convenience" if you have a
massive program, it makes it easier debugging etc or if multiple
people are working on it? From what you say, you could put all
declarations in say, "my_specialfile.c", use # include where
necessary, but it would not be as clear?

You have a fundamental misapprehension in your usage of header
files. Their purpose is not to isolate declarations, but to
publish them for use in other files. They expose the items in your
..c file that should be available elsewhere. A second line of
defense is the 'static' declaration, which prevents items from
being exposed accidentally and thus cluttering the global
namespace, with possible collisions with other files.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[mdh]

You have a fundamental misapprehension in your usage of header
files.

I mean no disrespect, but this is one the reasons I ask...to get rid
of pesky misapprehensions.

>Their purpose is not to isolate declarations, but to publish them for

use in other files. They expose the items in your .c file that should
be available elsewhere.

Ok...I see your point of view and like it. thanks.

>A second line of
defense is the 'static' declaration, which prevents items from
being exposed accidentally and thus cluttering the global
namespace, with possible collisions with other files.

You've lost me on that one...could you possibly expand a little more.

thanks

 

[mdh]

You have a fundamental misapprehension in your usage of header
files. Their purpose is not to isolate declarations, but to
publish them for use in other files.

I guess this does lead me back to the original essence of the question.
Then, why use the disignation .h as opposed to just using another .c
file to publish them for use in other files. Or, to ask another way,
does the compiler treat a .h file differently from a .c file?
thanks in advance.

 

[CBFalconer]

I guess this does lead me back to the original essence of the
question. Then, why use the disignation .h as opposed to just
using another .c file to publish them for use in other files. Or,
to ask another way, does the compiler treat a .h file differently
from a .c file?

For inclusion lines of the form

#include "file.ext"

there is no reliance on the extension. All the compiler does is to
inject the text of the included file at that point in the source
file. The use of .h is just a convenient convention. On file
systems without file extensions the convention can't even be
followed.

Normally one constructs a .h file to match each .c file, selecting
what to publish. This is pointless in programs that consist of
only one .c file.

For lines of the form:

#include <file.h>

things are much different, although in practice only the search
path changes. The compiler is allowed to do anything it wants,
because it knows what the published defines, prototypes, etc. are,
because they are specified in the standard. It may never
physically include anything in this case. The search path will
probably not include the directory in which the .c file resides.

On the use of static, most actual systems generate a relocatable
linkable object file from the compilation. That includes
definitions of entry points, especially to functions. The static
word prevents the publishing of the entry point to a function so
marked. This means that another file can freely use that name
without conflict. These details are system specific, and thus
fairly well off-topic here. Just remember that a static function
is private to the compilation unit.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Mike Wahler]

I guess this does lead me back to the original essence of the question.
Then, why use the disignation .h as opposed to just using another .c
file to publish them for use in other files. Or, to ask another way,
does the compiler treat a .h file differently from a .c file?
thanks in advance.

Chuck has already described the 'why' of header files. To
be sure you understand, I'll inform (or simply remind) you
that all that happens with #include is exactly that, 'include';
i.e. a 'pasting' of the contents of one file into another, at
the point of the #include directive.

The actual name of the file #included is completely arbitrary.
You could use e.g. ".x", ".y", ".z", or no 'extension' at all.
The ".h" is used by convention, one reason for which is that
that's what the language library's standard headers use(*).

So the answer to your question is no. The compiler doesn't
even see the code until after the #include directives have
already pasted the files together. This 'pasting' is done
by what is known as a 'preprocessor'. Then the compiler sees
the resulting code (known as a 'translation unit').

(*) FYI, the language does not require that these 'standard headers'
be implemented as files, they could be built into the implememtation.
However, they almost always are files (easier for vendors to maintain
and update their implementations).

HTH,
-Mike

 

[mdh]

...............

to Both Chuck and Mike...thank you...
It does clear this up.
Somewhat off-topic, This list is most supportive and appreciated.

 

[Gordon Burditt]

I guess this does lead me back to the original essence of the question.

Then, why use the disignation .h as opposed to just using another .c
file to publish them for use in other files. Or, to ask another way,
does the compiler treat a .h file differently from a .c file?

No, except sometimes if you give the .h file name as the name of a
compilation unit to compile.

But *PROGRAMMERS* treat them differently. The convention that foo.h
contains the external interface: declarations of functions, types,
and structures needed to use the code in foo.c is a useful one.

Often you can compile a whole program with many compilation units
with a command line like:

cc -o foo *.c

which won't work if you attempt to compile the header files as compilation
units on their own and they are named header.c .

Because compiler front-ends often use a file suffix to determine
what type a file is, the suffix you give to the compiler as the
file to compile may matter. For example, a .c suffix may indicate
C, a .cpp or .c++ or .C suffix may indicate C++, a .f suffix may
indicate FORTRAN, a .o file or .obj file or .a file is a compiled
object file which you don't compile but just pass to the linker.
A .h file might be compiled by the Hurd compiler, or be passed
directly to the linker, be ignored, or cause an error. All of this
is very system-dependent.

In this case, if bar.c contains:

#include "bar.h"

and bar.h contains a definition of main(),

the command
cc -o bar bar.h
may fail but the command
cc -o bar bar.c
may succeed. But there isn't a difference between including a .h
file and including a .c file with the same contents.

 

[mdh]

No, except sometimes if you give the .h file name as the name of a
compilation unit to compile.

But *PROGRAMMERS* treat them differently. .......

thanks