1 <!DOCTYPE HTML PUBLIC
"-//W3O//DTD W3 HTML 2.0//EN">
2 <!-- This collection of hypertext pages is Copyright 1995, 1996 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
7 <link rev=
"owner" href=
"mailto:scs@eskimo.com">
8 <link rev=
"made" href=
"mailto:scs@eskimo.com">
9 <title>Chapter
4: Functions and Program Structure
</title>
10 <link href=
"sx6h.html" rev=precedes
>
11 <link href=
"sx7a.html" rel=precedes
>
12 <link href=
"top.html" rev=subdocument
>
15 <H1>Chapter
4: Functions and Program Structure
</H1>
19 <blockquote>Functions break large computing tasks into smaller ones,
20 and enable people to build on what others have done
21 instead of starting over from scratch.
22 Appropriate functions hide details of operation
23 from parts of the program that don't need to know about them,
24 thus clarifying the whole,
25 and easing the pain of making changes.
26 </blockquote>Functions are probably the most import weapon
27 in our battle against software complexity.
28 You'll want to learn when it's appropriate
29 to break processing out into functions
30 (and also when it's not),
31 and
<em>how
</em> to set up function interfaces
32 to best achieve the qualities mentioned above:
38 </p><p>The quoted sentences above
39 show that a function does more than just save typing:
40 a well-defined function can be re-used later,
41 and eases the mental burden of thinking about a complex program
42 by freeing us from having to worry about all of it at once.
43 For a well-designed function,
45 we should either have to think about:
46 <OL><li>that function's internal implementation
47 (when we're writing or maintaining it);
49 <li>a particular call to the function
50 (when we're working with code which uses it).
51 </OL>But we should
<em>not
</em> have to
52 think about the internals when we're calling it,
54 about the callers when we're implementing the internals.
55 (We should perhaps think about the callers just enough to
56 ensure that the function we're designing will be easy to call,
58 we aren't accidentally setting up
59 so that callers will have to think about any internal details.)
61 we'll write a function which we only call once,
62 just because breaking it out into a function
63 makes things clearer and easier.
65 <blockquote>C has been designed to make functions efficient and easy to use;
66 C programs generally consist of many small functions
67 rather than a few big ones.
68 </blockquote>Some people worry about ``function call overhead,''
70 the work that a computer has to do to set up and return from a function call,
71 as opposed to simply doing the function's statements in-line.
72 It's a risky thing to worry about,
74 because as soon as you start worrying about it,
75 you have a bit of a disincentive to use functions.
76 If you're reluctant to use functions,
77 your programs will probably be
78 bigger and more complicated and harder to maintain
79 (and perhaps, for various reasons, actually
<em>less
</em> efficient).
80 </p><p>The authors choose not to get involved with
81 the system-specific aspects of separate compilation,
82 but we'll take a stab at it here.
83 We'll cover two possibilities,
84 depending on whether you're using a traditional command-line compiler
85 or a newer integrated development environment (IDE)
86 or other graphical user interface (GUI) compiler.
87 </p><p>When using a command-line compiler,
88 there are usually two main steps involved
89 in building an executable program
90 from one or more source files.
92 each source file is compiled,
93 resulting in an
<dfn>object file
</dfn>
94 containing the machine instructions
95 (generated by the compiler)
96 corresponding to the code in that source file.
98 the various object files are
<dfn>linked
</dfn> together,
99 with each other and with
<dfn>libraries
</dfn>
100 containing code for functions which you did not write
102 (such as
<TT>printf
</TT>),
103 to produce a final, executable program.
104 </p><p>Under Unix, the
<TT>cc
</TT> command can perform one or both steps.
105 So far, we've been using extremely simple invocations of
108 </pre>(section
1.1, page
6).
109 This invocation compiles a single source file,
111 and places the executable
112 (somewhat inconveniently)
113 in a file named
<TT>a.out
</TT>.
114 </p><p>Suppose we have a program which we're trying to build
115 from three separate source files,
116 <TT>x.c
</TT>,
<TT>y.c
</TT>, and
<TT>z.c
</TT>.
117 We could compile all three of them,
118 and link them together,
122 </pre>(see also page
70).
124 we could compile them separately:
125 the
<TT>-c
</TT> option to
<TT>cc
</TT> tells it to compile only,
127 Instead of building an executable,
128 it merely creates an object file,
129 with a name ending in
<TT>.o
</TT>,
130 for each source file compiled.
131 So the three commands
135 </pre>would compile
<TT>x.c
</TT>,
<TT>y.c
</TT>, and
<TT>z.c
</TT>
136 and create object files
<TT>x.o
</TT>,
<TT>y.o
</TT>, and
<TT>z.o
</TT>.
137 Then, the three object files could be linked together using
139 </pre>When the
<TT>cc
</TT> command is given an
<TT>.o
</TT> file,
140 it knows that it does not have to compile it
141 (it's an object file, already compiled);
142 it just sends it through to the link process.
143 </p><p>Here we begin to see one of the advantages of separate compilation:
144 if we later make a change to
<TT>y.c
</TT>,
145 only it will need recompiling.
146 (At some point you may want to learn about a program called
<TT>make
</TT>,
147 which keeps track of which parts need recompiling
148 and issues the appropriate commands for you.)
149 </p><p>Above we mentioned that the second,
150 linking step also involves pulling in library functions.
151 Normally, the functions from the Standard C library are linked
153 Occasionally, you must request a library manually;
154 one common situation under Unix
155 is that certain math routines are in a separate math library,
156 which is requested by using
<TT>-lm
</TT> on the command line.
157 Since the libraries must typically be searched
<em>after
</em>
158 your program's own object files are linked
159 (so that the linker knows which library functions your program uses),
160 any
<TT>-l
</TT> option must appear
161 <em>after
</em> the names of your files on the command line.
163 to link the object file
<TT>mymath.o
</TT>
164 (previously compiled with
<TT>cc -c mymath.c
</TT>)
165 together with the math library,
167 <pre> cc mymath.o -lm
168 </pre></p><p>Two final notes on the Unix
<TT>cc
</TT> command:
169 if you're tired of using the nonsense name
<TT>a.out
</TT>
170 for all of your programs,
171 you can use
<TT>-o
</TT> to give another name to the output (executable) file:
172 <pre> cc -o hello hello.c
173 </pre>would create an executable file named
<TT>hello
</TT>,
176 everything we've said about
<TT>cc
</TT>
177 also applies to most other Unix C compilers.
178 Many of you will be using
<TT>acc
</TT>
179 (a semistandard name for a version of
<TT>cc
</TT>
180 which
<em>does
</em> accept ANSI Standard C)
182 (the FSF's GNU C Compiler,
183 which also accepts ANSI C and is free).
184 </p><p>There are command-line compilers for MS-DOS systems which work similarly.
185 For example, the Microsoft C compiler comes with a
<TT>CL
</TT>
186 (``compile and link'') command,
187 which works almost the same as Unix
<TT>cc
</TT>.
188 You can compile and link in one step:
190 </pre>or you can compile only:
192 </pre>creating an object file named
<TT>hello.obj
</TT> which you can link later.
194 </p><p>The preceding has all been about command-line compilers.
195 If you're using some kind of integrated development environment,
196 such as Turbo C or the Microsoft Programmer's Workbench or Think C,
197 most of the mechanical details are taken care of for you.
198 (There's also less I can say here about these environments,
199 because they're all different.)
200 Typically there's a way to specify the list of files (modules)
201 which make up your project,
202 and a single ``build'' button which does whatever's required
203 to build (and perhaps even execute) your program.
204 <br></p><p><a href=
"sx7a.html" rel=subdocument
>section
4.1: Basics of Functions
</a></p>
205 <p><a href=
"sx7b.html" rel=subdocument
>section
4.2: Functions Returning Non-Integers
</a></p>
206 <p><a href=
"sx7c.html" rel=subdocument
>section
4.3: External Variables
</a></p>
207 <p><a href=
"sx7d.html" rel=subdocument
>section
4.4: Scope Rules
</a></p>
208 <p><a href=
"sx7e.html" rel=subdocument
>section
4.5: Header Files
</a></p>
209 <p><a href=
"sx7f.html" rel=subdocument
>section
4.6: Static Variables
</a></p>
210 <p><a href=
"sx7g.html" rel=subdocument
>section
4.7: Register Variables
</a></p>
211 <p><a href=
"sx7h.html" rel=subdocument
>section
4.8: Block Structure
</a></p>
212 <p><a href=
"sx7i.html" rel=subdocument
>section
4.9: Initialization
</a></p>
213 <p><a href=
"sx7j.html" rel=subdocument
>section
4.10: Recursion
</a></p>
214 <p><a href=
"sx7k.html" rel=subdocument
>section
4.11: The C Preprocessor
</a></p>
215 <p><a href=
"sx7l.html" rel=subdocument
>section
4.11.1: File Inclusion
</a></p>
216 <p><a href=
"sx7m.html" rel=subdocument
>section
4.11.2: Macro Substitution
</a></p>
217 <p><a href=
"sx7n.html" rel=subdocument
>section
4.11.3: Conditional Inclusion
</a></p>
221 <a href=
"sx6h.html" rev=precedes
>prev
</a>
222 <a href=
"sx7a.html" rel=precedes
>next
</a>
223 <a href=
"top.html" rev=subdocument
>up
</a>
224 <a href=
"top.html">top
</a>
227 This page by
<a href=
"http://www.eskimo.com/~scs/">Steve Summit
</a>
228 //
<a href=
"copyright.html">Copyright
</a> 1995,
1996
229 //
<a href=
"mailto:scs@eskimo.com">mail feedback
</a>