Chapter One
|
Table of Contents
Learning C++:
An Index of Entry Points
2. The A reference document on the basic elements of C++.
3. The Patterns
|
If you are reading this, you probably want to or
need to learn something about writing computer programs. You are about to
explore one of the most interesting, exciting areas coming out of modern
technology. And, we have to admit, it is also one of the harder skills of
the 20th century. Many people can't imagine something that is both hard
and exciting. Some might say that only a 'nerd' could say such a thing. We
leave the final decision up to you.
Programming is both a science and an art. That is part of the
excitement. To be sure, there are plenty of rules to follow when writing a
program and, since the interaction is with a machine, it has a certain
mechanical nature to it. But, any program you write is yours. It came out
of your head and is the product of your creative juices. This is
especially true as you venture beyond the basic formats presented in class
and this text. We urge you to discover the fun of that creative process by
exploring and experimenting. You can't write a program that will hurt the
computer, so go for it!
A. So What is Programming Anyway?
When you program your VCR, you 'tell' the VCR exactly what you want it
to do. Perhaps the command is: "Record the signal being transmitted on
channel 6 between 9 and 10 PM on June 18, 1996." Of course, one doesn't
speak directly to the VCR, but that is not the issue. The thing to observe
is how precise you have to be in instructing the VCR - whether one speaks
directly to it or pushes buttons on a remote. It is not acceptable to just
say or type, "Please record "E.R." next Tuesday. That is one of the first
things you will learn about computers and programming - the instructions
must be given in great detail and with no errors or ambiguities. To put it
differently,
Everyone who has ever used a computer knows this. If you type "COPPY"
at a computer keyboard when you mean COPY, the computer just sits there -
or worse, gives back one of those delightful computer error messages.
Contrast this with human behavior. If the sentence above was, "Computers
Is Stupid", you may wonder about the authors' knowledge of English but you
would understand the message.
Because computers are stupid, the languages we use to communicate our
instructions to them must be precise. You can't leave a computer
'guessing' or needing to figure out which of many items you are referring
to. Ambiguity is not allowed! For example, even if you have only been
working with one file for the last hour, you can't type, "COPY IT". You
must give the computer the name of the file in order to avoid any
ambiguity. (Researchers in the area of artificial
intelligence do hope someday to develop the kind of programs that will
provide computers with the smarts to handle ambiguity and error but that
is a long ways off. More important for us, the program that provides the
smarts will be written in the precise, detailed way being discussed
here.)
You may have observed situations involving computers where some
ambiguity seemed to be OK. For example, in operating systems such as DOS
and Unix you do not always have to tell the system which disk drive you
want to copy from. That is because the programmer of the copy command
specifically wrote into the code the rule:
Somebody had to handle the ambiguity - but it was not the computer!
B. Details, Details, Details
At this point we have learned a few things about
computer programs:
C. Programming Languages
What we are seeing here are different levels for
communicating with a computer. Computers directly 'understand' only what
is referred to as machine language. This is a language of 1's and
0's (or more precisely two voltage levels), a language that humans have a
most difficult time programming in.
Actually, there a number of machine languages, different ones for
different computer architectures. For example, the so-called IBM
compatibles understand one machine language, Macintosh computers
understand a different machine language, and RISC based Unix workstations
understand yet other machine languages. Each of these machine languages
has its own way of saying "Add these two numbers" or "Check to see if the
value in this memory location is greater than 0." This is why you can't
run software written for a Macintosh on a PC or vs. versa. If a piece of
software can be run on both types of computers, it has been written in
both languages - or somehow translated from one to the other.
Computer Scientists long ago
said "Forget it!" to this type of language and began the search for an
easier way to communicate with a computer. The first practical step was
Assembly Language, a language that pretty much follows the format
of machine language but has simple word-like codes corresponding to the
fundamental instructions of the computer architecture. For example, in
assembly language the word 'Add' might be used to represent the
combination of 1's and 0's that mean add at the machine language level. A
programmer would write a program in assembly language and then run a
program (often called an Assembler) that translated the program
into machine language. And, guess what - the assembler was probably
written in machine language. (Modern assembly languages are quite complex
but here is a relatively simple
example.)
This was an improvement but still
programming was a slow, tedious process and the programmer spent too much
time on tiny details. The next step involved the creation of the so
called third generation languages (after machine language and
assembly language). These languages allowed one to write one instruction
that looked a bit like simple English (or Spanish or ...) and that became
a number of machine language instructions when compiled. For example, one
could write one instruction that told the computer to do some set of
instructions 30 or 50 or 2000 times or tell the computer to make some kind
of comparison as in:
Now programs
were at least semi-readable and a programmer could focus more on the
actual problem being solved. Fortran was the first language of this type. Cobol, Pascal, Basic, and
'C' followed later. 'C++, the language you are studying here', is a later,
cleaned up version of 'C' with a number of important additional features.
Just as with Assembly language, programs written in
these newer, third generation languages need to be translated into machine
language. Whatever language one writes in, there must
be a translator program that turns the code you write into machine
language. For third generation languages such translators are called
compilers. Languages other than machine language all have their own
compilers and, as a matter of fact, each version of a language (such as
GNU C++ or Microsoft C++ or Borland C++) has its own compiler. A C++
compiler takes a file (or as we will see, a set of files) containing C++
code and attempts to translate it (or them) into the machine language for
some computer architecture, for example, Pentium PC's. If the compiler
encounters one or more lines of code that it cannot understand because the
programmer has made a 'grammatical' mistake in the use of C++, it outputs
error messages and does not complete the translation. Only successfully
translated code can be executed.
You will need to learn how to compile whatever version of C++ you are
using. Actually, you will need to learn much more than how to compile.
Modern programming languages come with a sophisticated environment for
writing, compiling, and debugging programs and you will need to have some
understanding of how to take advantage of these.
There have
been further advances in programming languages. One focus has been on
creating languages that are even more human like in form or style. These
are the so-called fourth and fifth generation languages.
A second focus has been on creating languages that support a more human
like form of problem solving or that have more sophisticated ways of
representing the complexities of a programming problem. This is where we
will focus much of our energy in the following pages - on ways to capture
the complexity of the real world in our programs. This is also one of the
strengths of C++ and one of the reasons it is the language of this text.
D. The Issue of Complexity Computer programs are both models of complexity
and complex products in themselves. OK, so what does this mean? First, let's deal with
"Computer programs are models of complexity.…" It may surprise you to know
that computer scientists sometimes debate whether or not Computer Science
is a science at all. And, if it is, what is the special area of study for
this science. One possible answer (the favorite of one of the authors) is
that Computer Science explores modeling, specifically, how to best
create computational models of the complexities of the real world - or
even imaginary worlds as in computer games. (For the moment allow us to
cheat on the word 'computational' and
simply let it mean 'executable on a computer'.) From this perspective, a computer program is a model of some aspect of
some part of some world. If whatever being modeled is at all complex, then
the computer program is a model of that complexity. We will see that
capturing the complexity of a 'world' can be a serious challenge,
requiring the best tools available. And now for the second part of that sentence:
Computer programs are not simple things. The complexity they are
attempting to model often makes the programs themselves quite complex -
thousands upon thousands of lines of code using thousands of names for
memory locations. Imagine a song with thousands's of verses and hundred's
of different possible refrains. Then imagine that sometimes part of a
verse is mixed in with part of another verse, that verses are sung with
one set of chords sometimes and with a different set of chords other
times, and that verses and refrains are sometimes repeated multiple times.
Oh, and don't forget that there are various harmonies, keys, and rhythms.
Put all this and you have some sense of the complexity of large programs.
E. Software Engineering The discipline or 'science' of managing both these types of complexity
is called software engineering and will be a major emphasis of this
material. Over the years there have been many strategies and tools
developed to help manage program complexity. Some of them, such as the use
of descriptive names for the memory used in a program or the
use of comments, and good indentation are relatively simple. Others
involve a potentially complex analysis of the programming task. All are a
mixture of creativity and discipline. Any creative activity which is meant to be brought to fruition requires
discipline. The writer must write and rewrite that poem or novel. The
painter must prepare paint and canvas then work and rework that piece of
art. The musician must spend long hours practicing, creating just the
right combination of effects in voice and instruments. The computer
programmer must carefully analyze and design a program before writing any
code, then, write and re-write the code to get it to perform exactly as
required, do so efficiently, provide an easy to work with user interface,
and be easy to understand and modify. Much of this material is devoted to discussing basic software
engineering strategies and tools we will expect you to incorporate into
the programming process. Some of these strategies and tools are not
necessarily fun or creative but when properly used they will allow you to
handle the complexity of the task you have been given. As you use them,
try to remember that they are the fruit of other people's frustration with
failed or very difficult programming efforts. They represent proven
techniques to ultimately make the programming task easier. And, an easier
task is a more fun task! |
Top of Chapter