Information AboutControl Flow |
| CATEGORIES ABOUT CONTROL FLOW | |
| control flowcontrol flow | |
| programming constructs | |
|
In Computer Science and in Computer Programming , Statements in Pseudocode or in a Program are normally ''obeyed'' (or ''executed'') one after the other in the order in which they are written (sequential flow of control). Most programming languages have control flow statements which allow variations in this sequential order:
The use of Subroutine s does not normally cause any control flow problems, but see the discussions below on early return, error recovery, and labels as parameters. At the Machine- / Assembly Language level, it is usually the case that the only instructions available for handling choice and/or loops are '' Goto '' and ''conditional goto'' (often known as variations of ''jump'' and/or ''branch''). Compiler s for high-level Programming Language s must translate all control-flow statements into these primitives. PRIMITIVES Labels In a few programming languages (e.g. Fortran , BASIC ), a label is just a whole number which appears at the beginning of a statement, e.g. 1234 X = 3 In many programming languages, a label is an Identifier . Success: print ("target has been found") < Historical note: Algol 60 allowed both whole numbers and identifiers as labels (both attached by colons to statements), but few if any implementations allowed whole numbers. Goto The most common form for the unconditional transfer of control is just goto label Conditional transfer of control varies from language to language, e.g. IF test THEN label IF (test) GOTO label if test '''then''' '''goto''' label; if (test) '''goto''' label; For a fuller discussion on the drawbacks of goto, see Goto . In brief, undisciplined use of goto leads to has shown in ''Structured Programming with go to Statements'' that disciplined use of goto may be necessary to emulate missing control-flow structures (see " Proposed Control Structures " below). A number of authors have pointed out that using goto is often acceptable, provided that control is transferred to some later statement (forward jump) and that control is not transferred into the middle of some other structured statement. Some of the control-flow statements available in high-level programming languages are effectively disguised gotos which comply with these conditions, e.g. break, '''continue''', '''return''' as found in C/C++. Subroutines The terminology for Subroutine s varies; they may alternatively be known as routines, procedures, or sometimes methods. If they can be used in an expression and return a result, they may also be known as functions. In the 1950's, computer memories were very small by current standards so subroutines were used primarily to reduce program size; a piece of code was written once and then used many times from various other places in the program. Nowadays, subroutines are more frequently used to help make a program more structured, e.g. by isolating some particular algorithm or hiding some particular data access method. If many programmers are working on a single program, subroutines can be used to help split up the work. Subroutines can be made much more useful by providing them with parameters, e.g. many programming languages have a built-in square root subroutine whose parameter is the number you wish to find the square root of. Some programming languages allow Recursion , i.e. subroutines can call themselves directly or indirectly. Certain algorithms such as Quicksort and various tree-traversals are very much easier to express in recursive form than in non-recursive form. The use of subroutines does slow a program down slightly, due to the overhead of passing parameters, calling the subroutine, entering the subroutine (may involve saving information on a stack), and returning. The actual overhead depends on both the hardware instructions available and on any software conventions which are used; excluding parameters, the overhead may range from 2 to 14 instructions, or worse. Some compilers may effectively insert the code of a subroutine Inline at the point of call to remove this overhead. In some programming languages, the only way of returning from a subroutine is by reaching the physical end of the subroutine. Other languages have a return statement. This is equivalent to a forward jump to the physical end of the subroutine and so does not complicate the control flow situation. There may be several such statements within a subroutine if required. In most cases, a call to a subroutine is only a temporary diversion to the sequential flow of control, and so causes no problems for control flow analysis. A few languages allow labels to be passed as parameters, in which case understanding the control flow becomes very much more complicated, since you may then need to understand the subroutine to figure out what might happen. Here is an example illustrating the use of a subroutine which returns a value, written side-by-side in BASIC and in PHP (a language similar to C). BASIC '''PHP''' |
20 Y |
DOUBLE(X) = double() |
|
NUM |
NUM 2 = 2 |
|
{ Style |
"font-size: 80% border: 1px solid black" border="1" cellpadding="2" |
|
SomeCollection '''do''':
| "" class="copylinks" target="_blank">:eachElement xxx |
|
{ Style |
"font-size: 80% border: 1px solid black" border="1" cellpadding="2" |
|
{ Style |
"font-size: 80% border: 1px solid black" border="1" cellpadding="2" |
|
|
|