home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Education
/
collectionofeducationcarat1997.iso
/
COMPUSCI
/
CPPTUT.ZIP
/
CHAP04.TXT
< prev
next >
Wrap
Text File
|
1990-07-20
|
22KB
|
473 lines
Chapter 4
FUNCTIONS
This chapter discusses the changes in the use of functions that
have been made to C++ in order to make programming more convenient
and to let the compiler do further checking for errors. A fair
amount of time is also spent on teaching the modern form of
function definition and prototyping.
Prototyping allows the compiler to do additional type checking for
your function calls which can aid in detecting programming errors.
The first two example programs in this chapter are designed to
teach prototyping and what it will do for you. Prototyping is a
relatively new addition to C, so even some experienced C
programmers are not familiar with it. If you have experience with
prototyping you can skip directly to the section named INLINE CODE
on page 4-4 of this chapter.
PROTOTYPES
_________________________________________________________________
Examine the file named PROTYPE1.CPP for our ================
first look at a prototype and an illustration of PROTYPE1.CPP
how it is used. The prototyping used in C++ is ================
no different than that used in ANSI-C.
Actually, many C programmers take a rather dim
view of prototyping and seem reluctant to use it, but with C++ it
is considerably more important and is in much heavier use. In
fact, prototyping is required to be used in C++.
A prototype is a limited model of a more complete entity to come
later. In this case, the full function is the complete entity to
come later and the prototype is illustrated in line 4. The
prototype gives a model of the interface to the function that can
be used to check the calls to the function for the proper number
of parameters and the correct types of parameters. Each call to
the function named do_stuff() must have exactly three parameters
or the compiler will give an error message. In addition to the
correct number of parameters, the types must be compatible or the
compiler will issue an error message. Notice that when the
compiler is working on lines 12 and 13, the type checking can be
done based on the prototype in line 4 even though the function
itself is not yet defined. If the prototype is not given, the
number of parameters will not be checked, nor will the types of the
parameters be checked. You will get an apparently good compile and
link, but the program may do some very strange things when it is
executed if the correct number of parameters are not used.
To write the prototype, simply copy the header from the function
to the beginning of the program and append a semicolon to the end
as a signal to the compiler that this is not a function but a
prototype. The variable names given in the prototype are optional
Page 4-1
Chapter 4 - Functions
and act merely as comments to the program reader since they are
completely ignored by the compiler. You could replace the variable
name wings in line 4 with your first name and there would be no
difference in compilation. Of course, the next person that had to
read your program would be somewhat baffled with your choice of
names.
In this case, the two function calls to this function, given in
lines 12 and 13, are correct so no error will be listed during
compilation.
Even though we wish to use the char type for eyes in the function,
we wish to use it as a number rather than as a character. The cast
to int in line 20 is required to force the printout of the
numerical value rather than an ASCII character. The next example
program is similar but without the cast to int.
COMPATIBLE TYPES
_________________________________________________________________
We mentioned compatible types earlier so we should review them just
a bit in order to make our discussion of prototyping complete.
Compatible types are any simple types that can be converted from
one to another in a meaningful way. For example, if you used an
integer as the actual parameter and the function was expecting a
float type as the formal parameter, the system would do the
conversion automatically, without mentioning it to you. This is
also true of a float changing to a char, or a char changing to an
int. There are definite conversion rules which would be followed.
These rules are given in great detail in section 3.2 of the draft
of the ANSI-C standard and are also given on page 198 of the second
edition of the K&R reference.
If we supplied a pointer to an integer as the actual parameter and
expected an integer as the formal parameter in the function, the
conversion would not be made because they are two entirely
different kinds of values. Likewise, a structure would not be
converted automatically to a long float, an array, or even to a
different kind of structure, they are all incompatible and cannot
be converted in any meaningful manner. The entire issue of type
compatibility as discussed in chapter 2 of this tutorial applies
equally well to the compatibility of types when calling a function.
Likewise, the type specified as the return type, in this case void,
must be compatible with the expected return type in the calling
statement, or the compiler will issue a warning.
HOW DOES PROTOTYPING WORK?
_________________________________________________________________
This is your chance to try prototyping for yourself and see how
well it works and what kinds of error messages you get when you do
certain wrong things. Change the actual parameters in line 12 to
Page 4-2
Chapter 4 - Functions
read (12.2, 13, 12345) and see what the compiler says about that
change. It will probably say nothing because they are all type
compatible. If you change it to read (12.0, 13), it will issue a
warning or error because there are not enough arguments given.
Likewise you should receive an error message if you change one of
the parameters in line 13 to an address by putting an ampersand in
front of one of the variable names. Finally, change the first word
in line 4 from void to int and see what kind of error message is
given. You will first be required to make the function header in
line 16 agree with the prototype, then you will find that there is
not a variable returned from the function. Finally, you will find
that there is a returned value that is not used in the calling
program. You should have a good feeling that prototyping is doing
something good for you after making all of those changes.
Be sure to compile and execute this program then make the changes
recommended above, attempting to compile it after each change.
A LITTLE MORE PROTOTYPING
_________________________________________________________________
Examine the next example program named ================
PROTYPE2.CPP for a little more information on PROTYPE2.CPP
prototyping. This program is identical to the ================
last one except for a few small changes. The
variable names have been omitted from the
prototype in line 4 merely as an illustration that they are
interpreted as comments by the C++ compiler. The function header
is formatted differently to allow for a comment alongside each of
the actual parameters. This should make the function header a
little more self explanatory. However, you should remember that
comments should not be used to replace good selection of variable
names. In this particular case, the comments add essentially
nothing to the clarity of the program.
WHAT DOES PROTOTYPING COST?
_________________________________________________________________
Prototyping is essentially free because it costs absolutely nothing
concerning the run time size or speed of execution. Prototyping
is a compile time check and slows down the compile time a
negligible amount because of the extra checking that the compiler
must