fall through v.
(n. `fallthrough', var.
`fall-through') 1. To exit a loop by exhaustion, i.e., by having
fulfilled its exit condition rather than via a break or exception
condition that exits from the middle of it. This usage appears to
be really old, dating from the 1940s and 1950s. 2. To fail
a test that would have passed control to a subroutine or some other
distant portion of code. 3. In C, `fall-through' occurs when the
flow of execution in a switch statement reaches a case label
other than by jumping there from the switch header, passing a point
where one would normally expect to find a break. A trivial
example:
switch (color)
{
case GREEN:
do_green();
break;
case PINK:
do_pink();
/* FALL THROUGH */
case RED:
do_red();
break;
default:
do_blue();
break;
}
The variant spelling /* FALL THRU */ is also common.
The effect of the above code is to do_green() when color is
GREEN, do_red() when color is RED,
do_blue() on any other color other than PINK, and
(and this is the important part) do_pink() and then
do_red() when color is PINK. Fall-through is
considered harmful by some, though there are contexts (such as
the coding of state machines) in which it is natural; it is
generally considered good practice to include a comment
highlighting the fall-through where one would normally expect a
break. See also Duff's device.
(n. `fallthrough', var.
`fall-through') 1. To exit a loop by exhaustion, i.e., by having
fulfilled its exit condition rather than via a break or exception
condition that exits from the middle of it. This usage appears to
be really old, dating from the 1940s and 1950s. 2. To fail
a test that would have passed control to a subroutine or some other
distant portion of code. 3. In C, `fall-through' occurs when the
flow of execution in a switch statement reaches a case label
other than by jumping there from the switch header, passing a point
where one would normally expect to find a break. A trivial
example:
switch (color)
{
case GREEN:
do_green();
break;
case PINK:
do_pink();
/* FALL THROUGH */
case RED:
do_red();
break;
default:
do_blue();
break;
}
The variant spelling /* FALL THRU */ is also common.
The effect of the above code is to do_green() when color is
GREEN, do_red() when color is RED,
do_blue() on any other color other than PINK, and
(and this is the important part) do_pink() and then
do_red() when color is PINK. Fall-through is
considered harmful by some, though there are contexts (such as
the coding of state machines) in which it is natural; it is
generally considered good practice to include a comment
highlighting the fall-through where one would normally expect a
break. See also Duff's device.
Related:
- Duff's device n.
The most dramatic use yet seen of fall through in C,
invented by Tom Duff when he was at L Trying to... - book titles:: There is a tradition in hackerdom of informally
tagging important textbooks and standards documents with the
dominant color of their covers or with some other conspicuous
feature of the cover.
Many of these are described in this lexicon under... - Red Book: n. 1. Informal name for one of the three standard
references on {{PostScript}} ("PostScript Language Reference
Manual",
Adobe Systems (Addison-Wesley, 1985; QA76.73.P67P67... - Red Book n.
1. Informal name for one of the four
standard references on PostScript ("PostScript Language
Reference Manual",
Adobe Systems (Addison-Wesley, 1985; QA76.73.P67P67... - Jacques: First, you must get to know your lane. Feel the slickness,
feel the slippery finish. Caresses it, experience it... - green card: n. [after the "IBM System/360 Reference Data"
card] A summary of an assembly language,
even if the color is not green. Less frequently... - Blue Book: n. 1. Informal name for one of the three standard
references on the page-layout and graphics-control language
{{PostScript}} ("PostScript Language Tutorial and Cookbook",
Adobe Systems, Addison-Wesley 1985, QA76.73.P67P68... - fencepost error n.
1. [common] A problem with the discrete
equivalent of a boundary condition,
often exhibited in programs by iterative loops.... - pathological adj.
1. [scientific computation] Used of a
data set that is grossly atypical of normal expected input,
esp. one that exposes a weakness or bug in whatever...
