| blob | bf262ecc8bd2088fa52ccc2e7d2475394da08563 |
2 <!-- This collection of hypertext pages is Copyright 1995-7 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
5 <html>
6 <head>
13 </head>
14 <body>
18 </p><p>A line of the form
19 <pre>
21 </pre>
22 or
23 <pre>
24 #include "filename.h"
25 </pre>
27 parsed, and compiled at that point.
30 line.)
31 For example,
32 suppose you got tired of retyping external function prototypes
33 such as
34 <pre>
35 extern int getline(char [], int);
36 </pre>
37 at the top of each source file.
38 You could instead place the prototype in a header file,
40 and then simply place
41 <pre>
42 #include "getline.h"
43 </pre>
45 (You might not find it worthwhile to create an entire header
46 file for a single function,
47 but if you had a package of several related function,
48 it might be very useful to place all of their declarations in
49 one header file.)
50 As we may have mentioned,
51 that's exactly what the Standard header files such as
53 (including external function prototype declarations)
54 having to do with various sets of Standard library functions.
56 you automatically get the prototypes and other declarations it contains,
58 precisely so that you will get
59 the prototypes and other declarations they contain.
63 in central, standard directories,
65 directory,''
66 or the directory containing the source file that's doing the
67 including.
69 Therefore,
72 (which someone else has written).
75 by the way, simply stands for ``header,''
77 sit at the top (head) of your source files,
78 and contain global declarations and definitions which you would
79 otherwise put there.
80 (That extension is not mandatory--you can theoretically name
82 traditional,
83 and recommended.)
84 </p><p>As we've already begun to see,
85 the reason for putting something in a header file,
87 several different source files,
88 is when the something
89 (whatever it is)
90 must be declared or defined consistently in all of the source
91 files.
92 If, instead of using a header file,
93 you typed the something in to each of the source files directly,
94 and the something ever changed,
95 you'd have to edit all those source files,
96 and if you missed one,
97 your program could fail in subtle (or serious) ways due
98 to the mismatched declarations
99 (i.e. due to the incompatibility between the new declaration in
100 one source file and the old one in a source file you forgot to
101 change).
102 Placing common declarations and definitions into header files
103 means that if they ever change, they only have to be changed in
104 one place,
105 which is a much more workable system.
106 </p><p>What should you put in header files?
107 <UL><li>External declarations
108 of global variables and functions.
111 in many places.
112 We said
114 that it was a grave error
116 to issue an external declaration in one place
117 saying that a variable or function has one type,
118 when the defining instance in some other place
119 actually defines it with another type.
120 (If the two places are two source files, separately compiled,
121 the compiler will probably not even catch the discrepancy.)
122 If you put the external declarations in a header file, however,
123 and include the header wherever it's needed,
124 the declarations are virtually guaranteed to be consistent.
125 It's a good idea to include the header in the source file where
126 the defining instance appears, too, so that the compiler can check
127 that the declaration and definition match.
128 (That is, if you ever change the type, you do still have to
129 change it in two places:
130 in the source file where the defining instance occurs, and in the
131 header file where the external declaration appears.
132 But at least you don't have to change it in an arbitrary number
133 of places,
134 and,
135 if you've set things up correctly, the compiler can catch any
136 remaining
137 mistakes.)
138 <li>Preprocessor macro definitions
139 (which we'll meet in the next section).
140 <li>Structure definitions (which we haven't seen yet).
141 <li>Typedef declarations (which we haven't seen yet).
143 files:
144 <UL><li>Defining instances of global variables.
145 If you put these in a header file,
146 and include the header file in more than one source file,
147 the variable will end up multiply defined.
148 <li>Function bodies
149 (which are also defining instances).
150 You don't want to put these in headers for the same reason--it's
151 likely that you'll end up with multiple copies of the function
152 and hence ``multiply defined'' errors.
153 People sometimes put commonly-used functions in header files
155 program where they use that function,
157 files making up a program,
158 but both of these are poor ideas.
159 It's much better to learn how to use your compiler or linker to
160 combine together separately-compiled object files.
161 </UL></p><p>Since header files typically contain only external declarations,
163 you have to understand just what does and doesn't happen
165 The header file may provide the declarations for some functions,
166 so that the compiler can generate correct code when you call them
167 (and so that it can make sure that you're calling them correctly),
169 the functions themselves.
170 The actual functions will be
171 combined
173 into your program
174 at the end of compilation,
176 The linker may have to get the functions out of libraries,
177 or you may have to tell the compiler/linker where to find them.
178 In particular,
179 if you are trying to use a third-party library
180 containing some useful functions,
181 the library will often come with a header file describing those functions.
182 Using the library is therefore a two-step process:
184 in the files where you call the library functions,
186 you must tell the linker to read in the functions from the library itself.
190 </p><hr>
191 <p>
192 Read sequentially:
197 </p>
198 <p>
202 </p>
203 </body>
204 </html>