usingc.txt

书名:C语言科学与艺术,以前交钱下载的

that it doesn't crash), and the student has absolutely no clue as to
what went wrong.

In addition to the problem of requiring an obscure calling convention,
scanf has several other properties that tend to be at least as
confusing.  One significant problem is that scanf makes error recovery
difficult to perform.  The return value from scanf indicates only the
number of matching fields, and it is impossible to determine easily, for
example, whether there was extra text on the input line.  If the result
is zero, indicating that no value has been read, how does the programmer
recover from that condition, particularly with respect to clearing text
from the current line?  A second problem is that using scanf requires
the student to have a much more detailed knowledge of how the input
system handles special characters.  If scanf is used to read an integer
from the console, and the user terminates that input by typing the
newline character, scanf will read the terminating newline and then put
it back in the input buffer using ungetc.  If the student then tries to
perform character input, that newline will be the first character read.
This behavior is extremely difficult to explain to the novice.  In fact,
all of these problems are beyond the scope of an introductory treatment,
and there is no way to give beginning students a complete explanation.

In order to understand how to solve this problem in a classroom setting,
the key is to recognize what experienced programmers do when they
encounter similar problems in the process of developing software.  As
programmers, we often encounter situations in which the details
necessary to implement a conceptually simple operation turn out to be
messy.  When this occurs, the standard approach is to hide the
complexity by defining a new function or procedure that encapsulates the
complexity and provides to its caller a clean and simple interface.

I believe that this same approach offers an ideal mechanism for
deferring discussion of C's more confusing features until students are
able to make sense of them.  In the specific case of scanf, for example,
one can mask the complexity by defining a new library that provides a
simplified I/O capability.  In the course at Stanford, the interface to
that library was provided by the header file "simpio.h", which gave
students access to the functions GetInteger and GetFloat, which read and
return an integer and floating-point value, respectively.  Armed with
this library, students read integer values by writing

          value = GetInteger();

This call takes the place of the earlier scanf construction and has
several advantages from the point of view of student understanding.
First, it is consistent with every other type of function that they see,
and its use involves no special syntactic "rules" that the compiler
cannot check.  Second, the library implementation offers much better
error checking and built-in recovery operations.  Third, the
implementation is defined so that GetInteger always reads a complete
line, and there is therefore never any confusion about whether the
terminating newline character remains in the input pipeline.  All in
all, students understand this mechanism much more easily, and can use it
without any significant difficulty.  The scanf function is then
introduced at a more appropriate point in the course, when it is also
possible to expose the implementation of the "simpio.h" interface.

I also used the course libraries to remedy other pedagogical problems
that tend to arise when using C.  For example, C includes no Boolean
type -- an omission that has serious negative implications for teaching.
Although the use of integers for this purpose might be acceptable for
experienced programmers, it has the effect of muddying completely one of
the central concepts that introductory students must master.  In my
course, I solved the dilemma by defining the type bool as an enumeration
consisting of the constants FALSE and TRUE, and then putting that
definition in a standard library that students use from the very
beginning of the course.  When the topic of Boolean data was first
mentioned, I noted in passing that the type bool is an extension
provided by the library.  Once that was said, I didn't mention it again
for the rest of the quarter.  For my students, there is quite definitely
a Boolean type.  Every condition they see, and every condition they
write has a proper Boolean form; the traditional C shortcuts that depend
on the equivalence of FALSE and zero never arise.  This approach leads
to a much better conceptual understanding of how to use Booleans and
improves programming style and practice.

The standard library used with the course also includes an error-
handling facility that makes it easy for students to think about error-
checking and other defensive programming strategies early in the course.
In the beginning, the error-handling facility is used simply to provide
a uniform mechanism for reporting errors and then terminating the
program.  Later in the course, I introduce more advanced facilities of
the error-handling package that allow students to trap those errors and
specify recovery actions, without changing the basic discipline.  The
facility is based on a more general exception-handling mechanism for C
[Roberts87].

4.  REACTIONS TO THE LIBRARY APPROACH

In reading through reviews of an introductory text based on this
approach, I was interested to find that the early introduction of
libraries, such as the "simpio.h" facility outlined in the preceding
section, proved to be rather controversial.  Several reviewers responded
very favorably, noting that no other textbook addresses the problem that
students are not prepared to handle C constructs in their full
generality.  Other reviewers, however, expressed strongly negative
reactions to my tactic of introducing specialized abstractions, such as
the use of GetInteger and GetFloat to mask the complexity of scanf.
These reviewers argued that I was changing the language or that I was
likely to distract the students by providing a mechanism that they would
"remember after the course is over, instead of remembering scanf." One
reader felt sufficiently strongly about this question to set an entire
sentence in italics: "If you're going to teach ANSI C, teach ANSI C, not
some modified local version of the language!"

I believe that the last comment cuts to the heart of the controversy.  I
was not trying to teach ANSI C.  I was trying to teach programming.  I
just happened to be using ANSI C because I believe that students who
learn programming using ANSI C will be better practitioners in the C
environment after they complete the course.

CS1 is not a language course alone.  Although learning a programming
language is an essential component of the introductory presentation,
there are many aspects of an introductory course that are entirely
independent of language choice.  Of these, one of the most important is
procedural abstraction as a technique for managing complexity.  Students
need to learn how to take a complex operation and encapsulate it as a
procedure call with a simple and consistent interface.  The fact that
our course follows its own advice with respect to library development
encourages students to do the same.

Last year's experimental course was extremely effective in getting
students to recognize the value of abstraction.  We introduced separate
compilation early and emphasized the importance of well-specified
interfaces as the link between the implementer of a module, who
understands the details, and the client of that module, who understands
only the abstract effect.  Our students had the standard troubles with
algorithms, problem solving, implementation details, and debugging, but
they did come to master the notion of an interface and recognize its
importance.  And the concept seemed to stay with them.  One of my
students wrote to me a year later:

      I want to let you know that I've applied with great success
      your libraries in the courses I've taken . . .; it's a great
      concept of yours to deal with abstractions so that when you
      design a package, you, the "client" are relieved of the
      underlying implementation and can concentrate on the
      particular algorithms of your particular program.

I don't, of course, claim credit for the concept, but I do believe that
the pedagogical emphasis on abstraction has paid off.

5.  EMPHASIZING GOOD PRACTICE

A second common concern is that C -- by virtue of the very power and
flexibility that have ensured its commercial success -- is far too great
a temptation for the beginning student.  C has a reputation as the
language of the hacker, a domain in which all concern for good
programming style or sound engineering practice are inevitably displaced
by a passion for writing the shortest possible program or the program
that generates the most efficient possible code.  This view is sometimes
encouraged by the pedagogical treatment.  In the years that C was
introduced in the "Programming Paradigms" course, the focus was on the
nitty-gritty details of C, such as pointer/array equivalence, the
increment/decrement operators, and the various syntactic shortcuts for
which C is notorious -- precisely the features students are most likely
to abuse.  One of the traditional handouts used in the course was titled
"C Gets Ugly," and it is not hard to imagine that some students would
turn this assessment into a self-fulfilling prophecy.

My own view is that the power of C is most destructive precisely when we
teach students to use good programming techniques in some other language
and then expect them to pick up C on their own.  It is at this point
that the temptation of power seems most seductive.  By teaching them
good programming style and emphasizing the importance of discipline as
we teach them about the language, we can produce solid programmers who
carry these skills forward to more advanced work.

Brian Reid, who was a professor at Stanford for several years, captured
the dilemma presented by the power of C in the simple observation:
"power tools can kill." In designing a new curriculum, a department has
the choice of (1) avoiding the use of such power tools until students
reach upper-level courses or (2) offering courses that include
appropriate "power tool safety" components at the introductory level.
We decided to opt for the second approach.

I believe it is useful to remember the following observation made by
Larry Flon, then at Carnegie Mellon [Flon75]:

      There does not now, nor will there ever, exist a programming
      language in which it is the least bit hard to write bad
      programs.

The key to writing good programs, just as much today as in 1975, is good
discipline.  If we teach that discipline, we will produce good
programmers.  If we do not, the choice of language barely matters.

6.  CONCLUSIONS

Over a two-year period, the Stanford Department of Computer Science has
redesigned its introductory course to use ANSI C, replacing Pascal as
the language of instruction.  To avoid some of the problems that
ordinarily accompany the use of C, we have adopted three strategies.
First, the course defers the introduction of some of the more difficult
features of the language by using libraries to encapsulate the
complexity of those features so that the student sees them only through
a simple abstract interface.  Second, we emphasize the idea of
procedural abstraction and modular interfaces from the very beginning of
the course, so that students themselves develop the skills necessary to
manage complexity when it arises.  Third, we focus throughout the course
on the discipline of software engineering, so that students come to
recognize -- and then to demonstrate by following our example -- that C
programs can be written so that they are elegant, clearly presented,
well-documented, and easily maintained.

REFERENCES

[Abelson85]    Harold Abelson and Gerald Sussman, with Julie Sussman,
               Structure and Interpretation of Computer Programs,
               Cambridge: MIT Press, 1985.

[Flon75]       Lawrence Flon, "On research in structured programming,"
               SIGPLAN Notices, Vol. 10, No. 10, October 1975.

[Frank90]      Thomas S. Frank and James F. Smith, "Ada as a CS1-CS2
               language," SIGCSE Bulletin, Vol. 22, No. 2, June 1990.

[Gabrini86]    Philippe Gabrini, J. Mack Adams, Barry Kurtz, "Converting
               from Pascal to Modula-2 in the Undergraduate Curriculum,"
               Proceedings of the Seventeenth SIGCSE Technical Symposium
               on Computer Science Education, February 1986.

[Kernighan88]  Brian Koffman and Dennis Ritchie, The C Programming
               Language, second edition, Englewood Cliffs: Prentice
               Hall, 1988.

[Koffman84]    Elliot B. Koffman, Philip Miller, and Caroline Wardle,
               "Recommended Curriculum for CS1, 1984," Communications of
               the ACM, Vol. 27, No. 10, October 1984.

[Koffman88]    Elliot B. Koffman, "The case for Modula-2 in CS1 and
               CS2," Proceedings of the Nineteenth SIGCSE Technical
               Symposium on Computer Science Education, February 1988.

[Mody91]       R. P. Mody, "C in Education and Software Engineering,"
               SIGCSE Bulletin, Vol. 23, No. 3, September 1991.

[Roberts89]    Eric Roberts, "Implementing Exceptions in C," Research
               Report #40, Digital Equipment Corporation/Systems
               Research Center, Palo Alto, California, March 1989.

[Winslow89]    Leon Winslow and Joseph Lang, "Ada in CS1," Proceedings
               of the Twentieth SIGCSE Technical Symposium on Computer
               Science Education, February 1989.