chapter4.html

c语言编程-c语言作者的书。英文原版。非常好。

<strong>Exercise 4-5.</strong> Add access to library functions like
<tt>sin</tt>, <tt>exp</tt>, and <tt>pow</tt>. See </tt>&lt;math.h&gt;</tt> in
<a href="appb.html#sb.4">Appendix B, Section 4</a>.
<p>
<strong>Exercise 4-6.</strong> Add commands for handling variables. (It's
easy to provide twenty-six variables with single-letter names.) Add a
variable for the most recently printed value.
<p>
<strong>Exercise 4-7.</strong> Write a routine <tt>ungets(s)</tt> that will
push back an entire string onto the input. Should <tt>ungets</tt> know about
<tt>buf</tt> and <tt>bufp</tt>, or should it just use <tt>ungetch</tt>?
<p>
<strong>Exercise 4-8.</strong> Suppose that there will never be more than one
character of pushback. Modify <tt>getch</tt> and <tt>ungetch</tt>
accordingly.
<p>
<strong>Exercise 4-9.</strong> Our <tt>getch</tt> and <tt>ungetch</tt> do not
handle a pushed-back <tt>EOF</tt> correctly. Decide what their properties
ought to be if an <tt>EOF</tt> is pushed back, then implement your design.
<p>
<strong>Exercise 4-10.</strong> An alternate organization uses
<tt>getline</tt> to read an entire input line; this makes <tt>getch</tt> and
<tt>ungetch</tt> unnecessary. Revise the calculator to use this approach.

<h2><a name="s4.4">4.4 Scope Rules</a></h2>
The functions and external variables that make up a C program need not all
be compiled at the same time; the source text of the program may be kept in
several files, and previously compiled routines may be loaded from libraries.
Among the questions of interest are
<ul>
<li>How are declarations written so that variables are properly declared
    during compilation?
<li>How are declarations arranged so that all the pieces will be properly
    connected when the program is loaded?
<li>How are declarations organized so there is only one copy?
<li>How are external variables initialized?
</ul>
Let us discuss these topics by reorganizing the calculator program into
several files. As a practical matter, the calculator is too small to be worth
splitting, but it is a fine illustration of the issues that arise in larger
programs.
<p>
The <em>scope</em> of a name is the part of the program within which the name
can be used. For an automatic variable declared at the beginning of a function,
the scope is the function in which the name is declared. Local variables of
the same name in different functions are unrelated. The same is true of the
parameters of the function, which are in effect local variables.
<p>
The scope of an external variable or a function lasts from the point at
which it is declared to the end of the file being compiled. For example,
if <tt>main</tt>, <tt>sp</tt>, <tt>val</tt>, <tt>push</tt>, and
<tt>pop</tt> are defined in one file, in the order shown above, that is,
<pre>
   main() { ... }

   int sp = 0;
   double val[MAXVAL];

   void push(double f) { ... }

   double pop(void) { ... }
</pre>
then the variables <tt>sp</tt> and <tt>val</tt> may be used in <tt>push</tt>
and <tt>pop</tt> simply by naming them; no further declarations are needed.
But these names are not visible in <tt>main</tt>, nor are <tt>push</tt> and
<tt>pop</tt> themselves.
<p>
On the other hand, if an external variable is to be referred to before it is
defined, or if it is defined in a different source file from the one where it
is being used, then an <tt>extern</tt> declaration is mandatory.
<p>
It is important to distinguish between the <em>declaration</em> of an external
variable and its <em>definition</em>. A declaration announces the properties
of a variable (primarily its type); a definition also causes storage to be
set aside. If the lines
<pre>
   int sp;
   double val[MAXVAL];
</pre>
appear outside of any function, they <em>define</em> the external variables
<tt>sp</tt> and <tt>val</tt>, cause storage to be set aside, and also serve as the
declarations for the rest of that source file. On the other hand, the lines
<pre>
   extern int sp;
   extern double val[];
</pre>
<em>declare</em> for the rest of the source file that <tt>sp</tt> is an <tt>int</tt>
and that <tt>val</tt> is a <tt>double</tt> array (whose size is determined
elsewhere), but they do not create the variables or reserve storage for them.
<p>
There must be only one <em>definition</em> of an external variable among all the
files that make up the source program; other files may contain <tt>extern</tt>
declarations to access it. (There may also be <tt>extern</tt> declarations in
the file containing the definition.) Array sizes must be specified with the
definition, but are optional with an <tt>extern</tt> declaration.
<p>
Initialization of an external variable goes only with the definition.
<p>
Although it is not a likely organization for this program, the functions
<tt>push</tt> and <tt>pop</tt> could be defined in one file, and the variables
<tt>val</tt> and <tt>sp</tt> defined and initialized in another. Then these
definitions and declarations would be necessary to tie them together:
<p>
&nbsp;&nbsp;<em>in file1</em>:
<pre>
      extern int sp;
      extern double val[];

      void push(double f) { ... }

      double pop(void) { ... }
</pre>
&nbsp;&nbsp;<em>in file2</em>:
<pre>
      int sp = 0;
      double val[MAXVAL];
</pre>
Because the <tt>extern</tt> declarations in <em>file1</em> lie ahead of and outside
the function definitions, they apply to all functions; one set of declarations
suffices for all of <em>file1</em>. This same organization would also bee needed
if the definition of <tt>sp</tt> and <tt>val</tt> followed their use in one file.

<h2><a name="s4.5">4.5 Header Files</a></h2>
Let is now consider dividing the calculator program into several source
files, as it might be is each of the components were substantially bigger.
The <tt>main</tt> function would go in one file, which we will call
<tt>main.c</tt>; <tt>push</tt>, <tt>pop</tt>, and their variables go into a
second file, <tt>stack.c</tt>; <tt>getop</tt> goes into a third,
<tt>getop.c</tt>. Finally, <tt>getch</tt> and <tt>ungetch</tt> go into a
fourth file, <tt>getch.c</tt>; we separate them from the others because they
would come from a separately-compiled library in a realistic program.
<p>
There is one more thing to worry about - the definitions and declarations
shared among files. As much as possible, we want to centralize this, so that
there is only one copy to get and keep right as the program evolves.
Accordingly, we will place this common material in a <em>header file</em>,
<tt>calc.h</tt>, which will be included as necessary. (The <tt>#include</tt>
line is described in <a href="#s4.11">Section 4.11</a>.) The resulting program
then looks like this:
<p>
<img src="pic41.gif">
<p>
There is a tradeoff between the desire that each file have access only to the
information it needs for its job and the practical reality that it is harder
to maintain more header files. Up to some moderate program size, it is
probably best to have one header file that contains everything that is to be
shared between any two parts of the program; that is the decision we made
here. For a much larger program, more organization and more headers would be
needed.

<h2><a name="s4.6">4.6 Static Variables</a></h2>
The variables <tt>sp</tt> and <tt>val</tt> in <tt>stack.c</tt>, and <tt>buf</tt> and
<tt>bufp</tt> in <tt>getch.c</tt>, are for the private use of the functions in their
respective source files, and are not meant to be accessed by anything else. The
<tt>static</tt> declaration, applied to an external variable or function, limits
the scope of that object to the rest of the source file being compiled.
External <tt>static</tt> thus provides a way to hide names like <tt>buf</tt> and
<tt>bufp</tt> in the <tt>getch-ungetch</tt> combination, which must be external so they
can be shared, yet which should not be visible to users of <tt>getch</tt> and
<tt>ungetch</tt>.
<p>
Static storage is specified by prefixing the normal declaration with the word
<tt>static</tt>. If the two routines and the two variables are compiled in one
file, as in
<pre>
   static char buf[BUFSIZE];  /* buffer for ungetch */
   static int bufp = 0;       /* next free position in buf */

   int getch(void) { ... }

   void ungetch(int c) { ... }
</pre>
then no other routine will be able to access <tt>buf</tt> and <tt>bufp</tt>, and
those names will not conflict with the same names in other files of the same
program. In the same way, the variables that <tt>push</tt> and <tt>pop</tt> use for
stack manipulation can be hidden, by declaring <tt>sp</tt> and <tt>val</tt> to be
<tt>static</tt>.
<p>
The external <tt>static</tt> declaration is most often used for variables,
but it can be applied to functions as well. Normally, function names are
global, visible to any part of the entire program. If a function is declared
<tt>static</tt>, however, its name is  invisible outside of the file in which
it is declared.
<p>
The <tt>static</tt> declaration can also be applied to internal variables.
Internal <tt>static</tt> variables are local to a particular function just as
automatic variables are, but unlike automatics, they remain in existence
rather than coming and going each time the function is activated. This means
that internal <tt>static</tt> variables provide private, permanent storage
within a single function.
<p>
<strong>Exercise 4-11.</strong> Modify <tt>getop</tt> so that it doesn't need to use
<tt>ungetch</tt>. Hint: use an internal <tt>static</tt> variable.

<h2><a name="s4.7">4.7 Register Variables</a></h2>
A <tt>register</tt> declaration advises the compiler that the variable in
question will be heavily used. The idea is that <tt>register</tt> variables are
to be placed in machine registers, which may result in smaller and faster
programs. But compilers are free to ignore the advice.
<p>
The <tt>register</tt> declaration looks like
<pre>
   register int  x;
   register char c;
</pre>
and so on. The <tt>register</tt> declaration can only be applied to automatic
variables and to the formal parameters of a function. In this later case, it
looks like
<pre>
   f(register unsigned m, register long n)
   {
       register int i;
       ...
   }
</pre>
In practice, there are restrictions on register variables, reflecting the
realities of underlying hardware. Only a few variables in each function may
be kept in registers, and only certain types are allowed. Excess register
declarations are harmless, however, since the word <tt>register</tt> is
ignored for excess or disallowed declarations. And it is not possible to take
the address of a register variable (a topic covered in <a
href="chapter5.html">Chapter 5</a>), regardless of whether the variable is
actually placed in a register. The specific restrictions on number and types
of register variables vary from machine to machine.

<h2><a name="s4.8">4.8 Block Structure</a></h2>
C is not a block-structured language in the sense of Pascal or similar
languages, because functions may not be defined within other functions. On
the other hand, variables can be defined in a block-structured fashion within
a function. Declarations of variables (including initializations) may follow
the left brace that introduces <em>any</em> compound statement, not just the
one that begins a function. Variables declared in this way hide any
identically named variables in outer blocks, and remain in existence until
the matching right brace. For example, in
<pre>
   if (n > 0) {
       int i;  /* declare a new i */

       for (i = 0; i &lt; n; i++)
           ...
   }
</pre>
the scope of the variable <tt>i</tt> is the ``true'' branch of the
<tt>if</tt>; this <tt>i</tt> is unrelated to any <tt>i</tt> outside the
block. An automatic variable declared and initialized in a block is
initialized each time the block is entered.
<p>
Automatic variables, including formal parameters, also hide external variables
and functions of the same name. Given the declarations
<pre>
   int x;
   int y;

   f(double x)
   {
       double y;
   }
</pre>
then within the function <tt>f</tt>, occurrences of <tt>x</tt> refer to the parameter,
which is a <tt>double</tt>; outside <tt>f</tt>, they refer to the external <tt>int</tt>.
The same is true of the variable <tt>y</tt>.
<p>
As a matter of style, it's best to avoid variable names that conceal names in
an outer scope; the potential for confusion and error is too great.

<h2><a name="s4.9">4.9 Initialization</a></h2>
Initialization has been mentioned in passing many times so far, but always
peripherally to some other topic. This section summarizes some of the rules,
now that we have discussed the various storage classes.
<p>
In the absence of explicit initialization, external and static variables are
guaranteed to be initialized to zero; automatic and register variables have
undefined (i.e., garbage) initial values.
<p>
Scalar variables may be initialized when they are defined, by following the
name with an equals sign and an expression:
<pre>
   int x = 1;
   char squota = '\'';
   long day = 1000L * 60L * 60L * 24L; /* milliseconds/day */
</pre>
For external and static variables, the initializer must be a constant
expression; the initialization is done once, conceptionally before the program
begins execution. For automatic and register variables, the initializer is not
restricted to being a constant: it may be any expression involving previously
defined values, even function calls. For example, the initialization of the
binary search program in <a href="chapter3.html#s3.3">Section 3.3</a> could
be written as
<pre>
   int binsearch(int x, int v[], int n)
   {
       int low = 0;
       int high = n - 1;
       int mid;
       ...
   }
</pre>
instead of
<pre>
       int low, high, mid;

       low = 0;
       high = n - 1;
</pre>
In effect, initialization of automatic variables are just shorthand for
assignment statements. Which form to prefer is largely a matter of taste. We
have generally used explicit assignments, because initializers in
declarations are harder to see and further away from the point of use.
<p>
An array may be initialized by following its declaration with a list of
initializers enclosed in braces and separated by commas. For example, to
initialize an array <tt>days</tt> with the number of days in each month:
<pre>
   int days[] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
</pre>
When the size of the array is omitted, the compiler will compute the length by
counting the initializers, of which there are 12 in this case.
<p>
If there are fewer initializers for an array than the specified size, the
others will be zero for external, static and automatic variables. It is an
error to have too many initializers. There is no way to specify repetition
of an initializer, nor to initialize an element in the middle of an array