chap04.htm

来自「Since the field of object oriented progr」· HTM 代码 · 共 405 行 · 第 1/2 页

This is because passing a large structure can be done very efficiently
if it is passed by reference.

<P><B>DEFAULT PARAMETERS</B>

<P>Example program ------> <B><A HREF="DEFAULT.CPP">DEFAULT.CPP</A></B>

<P>Examine the file named DEFAULT.CPP for an example of the use of default
parameters in C++. This program really looks strange since it contains
default values for some of the parameters in the prototype, but these default
values are very useful as we will see shortly.

<P>This prototype says that the first parameter named <B>length </B>must
be given for each call of this function because a default value is not
supplied. The second parameter named <B>width</B>, however, is not required
to be specified for each call, and if it is not specified, the value 2
will be used for the variable <B>width </B>within the function. Likewise,
the third parameter is optional, and if it is not specified, the value
of 3 will be used for <B>height </B>within the function.

<P>In line 11 of this program, all three parameters are specified so there
is nothing unusual about this call from any other function call we have
made. Only two values are specified in line 12 however, so we will use
the default value for the third parameter and the system acts as if we
called it with <B>get_volume(x,y,3)</B> since the default value for the
third value is 3. In line 13, we only specified one parameter which will
be used for the first formal parameter, and the other two will be defaulted.
The system will act as if we had called the function with<B> get_volume(x,2,3).</B>
Note that the output from these three lines is reversed. This will be explained
shortly.

<P>There are a few rules which should be obvious but will be stated anyway.
Once a parameter is given a default value in the list of formal parameters,
all of the remaining must have default values also. It is not possible
to leave a hole in the middle of the list, only the trailing values can
be defaulted. Of course, the defaulted values must be of the correct types
or a compiler error will be issued. The default values can be given in
either the prototype or the function header, but not in both. If they were
given in both places, the compiler must not only use the default value,
but it must carefully check to see that both values are identical. This
could further complicate an already very complicated problem, that of writing
a C++ compiler, so this rule was instituted for the benefit of the compiler
writer.

<P>As a matter of style, it is highly recommended that the default values
be given in the prototype rather than in the function. The reason will
be obvious when we begin using object oriented programming techniques.

<P><B>WHY IS THE OUTPUT SCRAMBLED?</B>

<P>When the compiler finds a <B>cout </B>statement, the complete line of
code is initially scanned from right to left to evaluate any functions,
then the data is output field by field from left to right. Therefore in
line 11, <B>get_volume()</B> is evaluated with its internal output displayed
first. Then the fields of the <B>cout </B>are displayed from left to right
with "Some box data is" displayed next. Finally, the result of the return
from <B>get_volume()</B> is output in <B>int </B>format, the type of the
returned value. The end result is that the output is not in the expected
order when lines 11 through 13 are executed. (The output is not what you
would intuitively expect to happen so appears to be a deficiency in the
language. A call to Borland International, the writers of Turbo C++ and
Borland C++, verified that this code is operating correctly.) Your compiler
may not execute this program correctly. You may need to find a compiler
switch to permit mixing <B>printf()</B> and <B>cout </B>outputs, or you
may need to convert the <B>printf()</B> statements to <B>cout </B>outputs
to get the program to operate properly.

<P>We still have the problem of mixing <B>cout </B>and <B>printf() </B>output
as discussed in chapter 1 while studying the program named MESSAGE.CPP.
Eventually, all conforming compilers will overcome this problem.

<P>Lines 15 through 18 are similar to any two of the lines of code in lines
11 through 13, but are each separated into two lines so the output is in
the expected order.

<P>Be sure to compile and execute DEFAULT.CPP after you understand it.
Note that the funny output order will appear again later in this tutorial.

<P><B>VARIABLE NUMBER OF ARGUMENTS</B>

<P>Example program ------> <B><A HREF="VARARGS.CPP">VARARGS.CPP</A></B>

<P>Examine the program named VARARGS.CPP for an illustration of the use
of a variable number of arguments in a function call.

<P>We have gone to a lot of trouble to get the compiler to help us by carefully
checking how many parameters we use in the function calls and checking
the types of the parameters. On rare occasion, we may wish to write a function
that uses a variable number of parameters. The <B>printf()</B> function
is a good example of this. ANSI-C has a series of three macros available
in the "stdarg.h" header file to allow the use of a variable number of
arguments. These are available for use with C++ also, but we need a way
to eliminate the stronger type checking that is done with all C++ functions.
The three dots illustrated in line 6 will do this for us. This prototype
says that a single argument of type <B>int </B>is required as the first
parameter, then no further type checking will be done by the compiler.

<P>You will note that the main program consists of three calls to the function,
each with a different number of parameters, and the system does not balk
at the differences in the function calls. In fact, you could put as many
different types as you desire in the calls. As long as the first one is
an <B>int </B>type variable, the system will do its best to compile and
run it for you. Of course the compiler is ignoring all type checking beyond
the first parameter so it is up to you to make sure you use the correct
parameter types in this call.

<P>In this case, the first parameter gives the system the number of additional
parameters to look for and handle. In this simple program, we simply display
the numbers on the monitor to illustrate that they really did get handled
properly.

<P>Of course, you realize that using a variable number of arguments in
a function call can lead to very obscure code and should be used very little
in a production program, but the capability exists if you need it. Be sure
to compile and execute this program.

<P><B>FUNCTION NAME OVERLOADING</B>

<P>Example program ------> <B><A HREF="OVERLOAD.CPP">OVERLOAD.CPP</A></B>

<P>Examine the file named OVERLOAD.CPP for an example of a program with
a few function names overloaded. This is not possible in ANSI-C, but is
perfectly legal and in fact used quite regularly in C++. At first this
will seem a bit strange, but it is one of the keystones of object oriented
programming. You will see its utility and purpose very clearly in later
chapters of this tutorial.

<P>You will notice in this example program that there are three functions,
in addition to the main function, and all three have the same name. Your
first question is likely to be, "Which function do you call when you call
<B>do_stuff()</B>?" That is a valid question and the answer is, the function
that has the correct number of formal parameters of the correct types.
If <B>do_stuff()</B> is called with an integer value or variable as its
actual parameter, the function beginning in line 25 will be called and
executed. If the single actual parameter is of type <B>float</B>, the function
beginning in line 30 will be called, and if two floats are specified, the
function beginning in line 36 will be called.

<P>It should be noted that the return type is not used to determine which
function will be called. Only the types of the formal parameters are used
to determine which overloaded function will be called.

<P>The keyword <B>overload </B>used in line 4 tells the system that you
really do intend to overload the name <B>do_stuff</B>, and the overloading
is not merely an oversight. This is only required in very early versions
of C++. Newer versions of C++ do not require the keyword overload but,
at least for the time being, allows it to be used to prevent breaking the
existing body of C++ code. It is not necessary to use this keyword because,
when overloading is used in C++, it is generally used in a context in which
it is obvious that the function name is overloaded.

<P>When the final ANSI-C++ standard is completed, the use of this word
may not be permitted. As was mentioned earlier, the C++ language is changing
and we must be willing to change with it.

<P>The actual selection of which function to call is done at compile time,
not at execution time, so the program is not slowed down. If each of the
overloaded function names were changed to different names, each being unique,
there would be no difference in execution size or speed of the resulting
program.

<P>Overloading of function names may seem very strange to you, and it is
strange if you are used to the rules of K&amp;R or ANSI-C programming.
As you gain experience with C++, you will feel very comfortable with this,
and you will use it a lot in your C++ programming.

<P>Note the use of the keyword <B>const </B>used in some of the function
prototypes and headers. Once again, this prevents the programmer from accidentally
changing the formal parameter within the function. In a function as short
as these, there is no real problem with an accidental assignment. In a
real function that you occasionally modify, you could easily forget the
original intention of the use of a variable and attempt to change it during
an extended debugging session.

<P><B>PROGRAMMING EXERCISES</B>
<OL>
<LI>
Change the type of <B>wings </B>in the prototype of PROTYPE1.CPP to <B>float
</B>so that it disagrees with the function definition to see if you get
a compilation error.</LI>

<LI>
Change the function definition in PROTYPE1.CPP to agree with the changed
prototype. Compile and execute the program without changing the calls in
lines 12 and 13. Explain the results.</LI>

<LI>
In DEFAULT.CPP, remove the default value from the prototype for <B>height
</B>only to see what kind of compiler error you get. Only the last values
of the list can be defaulted.</LI>

<LI>
In OVERLOAD.CPP, change the names of the three functions so that each is
a unique name and compare the size of the resulting executable file with
that given for the present program.</LI>
</OL>
<A HREF="chap05.htm">Advance to Chapter 5</A>

<P><A HREF="cpplist.htm">Return to the Table of Contents</A>
</BODY>
</HTML>