Chapter 9 Subprograms Sections 1-5 and 9. Copyright © 2007 Addison-Wesley. All rights reserved. 1–2 Introduction Two fundamental abstraction facilities

Chapter 9

Subprograms

Sections 1-5 and 9

Copyright © 2007 Addison-Wesley. All rights reserved. 1–2

Introduction

• Two fundamental abstraction facilities– Process abstraction - subprograms

• Emphasized from the beginning

– Data abstraction - classes• Emphasized in the 1980s


Design Issues for Subprograms

• What parameter passing methods are provided?

• Are parameter types checked?• Are local variables static or dynamic?• Can subprogram definitions appear in other

subprogram definitions?• Can subprograms be overloaded?• Can subprogram be generic?• Any limits on parameter and return types?


Subprograms

• A subprogram is a collection of statements that can be executed from multiple points within a program – Procedures are collection of statements that define

parameterized operations• void methods

– Functions structurally resemble procedures but are semantically modeled on mathematical functions

• Return values• They are expected to produce no side effects• In practice, program functions have side effects


Basic Definitions• Subprogram definition describes interface to

and the actions of the subprogram abstraction• Subprogram call is explicit request that the

subprogram be executed• Subprogram header is the first part of the

definition, including the name, the kind of subprogram, and the formal parameters

• Parameter profile (aka signature) is the number, order, and types of the parameters

• Protocol is parameter profile plus return type for a function


Basic Definitions (continued)

• Subprogram declaration provides the protocol of the subprogram– Function declarations in C and C++ are often

called prototypes

• Formal parameter is a variable listed in the header and used to access the argument in the subprogram

• Actual parameter (argument) represents a value or address used in the subprogram call statement


Correspondence between Parameters and Arguments

• Positional– Actual parameters are bound to formal parameters

by position• the first actual parameter is bound to the first formal

parameter and so forth

– Safe and effective

• Keyword– The name of the formal parameter to which an actual

parameter is to be bound is specified with the actual parameter

– Parameters can appear in any order


Keyword Parameters

• Supported in Ada, Fortran 95, Python• Python

– A function defined bydef foo( a, b, c): print a, b, c– can be called with positional argumentsfoo( 1, 2, 3)– or with keyword argumentsfoo( b=2, a=1, c=3)


Default Parameter Values

• Python– A function defined by

def foo( a, b=2, c=3):

print a, b, c– can be called with 1, 2 or 3 arguments

• a must be supplied

foo(1)

foo(2, 3)

foo( a=1, c=3)


Defaults without Keyword Parameters

• C++– Keyword parameters are not supported– Default values are supported– Parameters with default values must come

at end of parameter list– The argument list cannot skip positions

• It must contain arguments 0 to i where i goes from the last parameter with no default to the last possible argument


Variatic Subprograms

• Sometimes you need subprograms with a variable number of arguments– printf in C and Java

• Python

– a parameter with a * in front of the name is a list


Local Referencing Environments

• Local variables can be stack-dynamic (bound to storage at run-time)– Support for recursion– Requires less memory for storage of locals – Allocation/de-allocation, initialization time– Indirect addressing– Subprograms cannot be history sensitive

• Local variables can be static– More efficient (no indirection)– No run-time overhead– Cannot support recursion


Parameter Passing Methods

• We discuss these at several different levels:– Semantic models

• in mode• out mode• inout mode

– Conceptual models of transfer:

1. Physically move a value

2. Move an access path


Models of Parameter Passing


Parameter Passing Methods

• Ways in which parameters are transmitted to and/or from called subprograms– Pass-by-value– Pass-by-result– Pass-by-value-result– Pass-by-reference– Pass-by-name


Pass-by-Value (In Mode)

• The value of the actual parameter is used to initialize the corresponding formal parameter– Normally implemented by copying– Can be implemented by transmitting an

access path but not recommended (enforcing write protection is not easy)

– When copies are used, additional storage is required

– Storage and copy operations can be costly


Pass-by-Result (Out Mode)

• No value is transmitted to the subprogram– The corresponding formal parameter acts as

a local variable• Its value is transmitted to caller’s actual parameter

when control is returned to the caller

– Require extra storage location and copy operation

• Potential problem: sub(p1, p1); whichever formal parameter is copied back last will represent the current value of p1


Pass-by-Value-Result (inout Mode)

• A combination of pass-by-value and pass-by-result

• Sometimes called pass-by-copy• Formal parameters have local

storage• Disadvantages:

– Those of pass-by-result– Those of pass-by-value


Pass-by-Reference (Inout Mode)

• Pass an access path• Passing process is efficient

– no copying and no duplicated storage

• Disadvantages– Slower accesses (compared to pass-

by-value) to formal parameters– Potentials for un-wanted side effects– Un-wanted aliases (access

broadened)


Pass-by-Name

• By textual substitution

• Formals are bound to an access method at the time of the call, but actual binding to a value or address takes place at the time of a reference or assignment

• Allows flexibility in late binding

• Macros are a form of pass by name


Parameter Passing Example Main { A = 2; B = 5; C = 8; D = 9; P(A, B, C, D); write(A, B, C, D);}

P(U, V, W, X) { V = U+A; W = A+B; A = A+1; X = A+2; write(U, V, W, X)}

Pass by Value Result

Pass by Reference

Pass by value

DCBAParameter mode


Implementation of Parameter-Passing

• In most languages parameter communication takes place thru the run-time stack

• Pass-by-reference are the simplest to implement; only an address is placed in the stack

• A subtle but fatal error can occur with pass-by-reference and pass-by-value-result: a formal parameter corresponding to a constant can mistakenly be changed


In Practice

• FORTRAN started out using pass-by-reference, later allowed pass-by-value-result

• ALGOL 60 used pass-by-name by default with pass-by-value optional

• C uses pass-by-value; get pass-by-reference using pointers

• Pascal, Modula-2 and C++ use pass-by-value by default; pass-by-reference is optional

• Ada provides all three semantic modes • Java uses pass-by-value exclusively but use of

object references results in pass-by-reference behavior of objects


Type Checking Parameters• Considered very important for reliability

• FORTRAN 77 and original C: none

• Pascal, FORTRAN 90, Java, and Ada: it is always required

• ANSI C and C++: choice is made by the user– Prototypes

• Scripting languages (Perl, JavaScript, PHP) do not require type checking


Design Considerations for Parameter Passing

• Two important considerations– Efficiency– One-way or two-way data transfer

• But the above considerations are in conflict– Good programming suggest limited access to

variables, which means one-way whenever possible

– But pass-by-reference is more efficient to pass structures of significant size

• Also provides more flexibility


Return Values for Functions

• What types of return values are allowed?– Most imperative languages restrict the return

types– C allows any type except arrays and

functions– C++ is like C but also allows user-defined

types– Ada allows any type– Java and C# methods can return any type– Scheme can return functions


Ruby Blocks

• In Ruby, a block is a chunk of code that can be passed to a method– often used with iterators

• Two formsdo <statements> end{|<paramlist>| <statements }

• In method that uses the block, it is executed by typing yield

• Blocks are closures– retain the environment in which they were

called


Thunks

Documents

Chapter 9 Subprograms Sections 1-5 and 9. Copyright © 2007 Addison-Wesley. All rights reserved. 1–2 Introduction Two fundamental abstraction facilities