6.8.4 Selection statements 1740 might have to be written as: 1 { 2 x=y; 3 if (x != 0) 4 / * . * / 5 } Neither of these reasons could be said to contain an actual benefit. The cost associated with side effects in controlling expressions is the possibility that they will go unnoticed by a reader of the source (especially if scanning along the left edge looking for assignments). 770 reading kinds of The most common form of side effect in a controlling expression is assignment, in particular simple assignment. The case where the author of the code intended to type an equality operator, rather than a simple assignment operator is a fault and these coding guidelines are not intended to recommend against the use of constructs that are obviously faults. However, it is possible that a reader of the visible source will mistake 0 guidelines not faults a simple assignment for an equality operator (the token == is much more likely than = in the context of a controlling expression) and reducing the likelihood of such a mistake occurring is also a cost reduction. 1740 controlling expression if statement This discussion has referred to controlling expressions as if these costs and benefits apply to their use in all contexts (i.e., selection and iteration statements). The following example shows that writing code to avoid the occurrence of side effects in controlling expressions contained with iteration statements requires two, rather than one, assignments to be used. 1 extern int glob_1, 2 glob_2; 3 4 void f_1(void) 5 { 6 if (glob_1 = glob_2) 7 ; 8 while ((glob_1 = glob_2 + 1) != 3) 9 { / * . * / } 10 } 11 12 void f_2(void) 13 { 14 { 15 glob_1 = glob_2; / * Single statement. * / 16 if (glob_1 != 0) 17 ; 18 } 19 20 glob_1 = glob_2 + 1; / * Statement 1: always occurs. * / 21 while (glob_1 != 3) 22 { 23 / * . * / 24 glob_1 = glob_2 + 1; / * Statement 2: occurs after every iteration. * / 25 } 26 } Duplicating the assignment to glob_1 creates a maintenance dependency (any changes to one statement need to be reflected in the other). The increase in cost caused by this maintenance dependency is assumed to be greater than the cost reduction achieved from reducing the likelihood of a simple assignment operator being mistaken treated as an equality operator. Cg 1740.1 The simple assignment operator shall not occur in the controlling expression of an if statement. June 24, 2009 v 1.2 6.8.4 Selection statements 1741 Experience has shown that there are a variety of other constructs, appearing in a controlling expression, that developer have difficulty comprehending, or simply miscomprehend when scanning the source. However, no other constructs are discussed here. The guideline recommendation dealing with the use of the assignment operator has the benefit of simplicity and frequency of occurrence. It was difficult enough analyzing the cost/benefit case for simple assignment and others are welcome to address more complicated cases. Experience shows that many developers use the verbal form “if expression is not true then” when thinking about the condition under which an else form is executed. This use of not can lead to double negatives when reading some expressions. For instance, possible verbal forms of expressing the conditions under which the arms of an if statement are executed include: 1 if (!x) 2 a(); / * Executed if not x. * / 3 else 4 b(); / * Executed if not x is not true. * / 5 / * Executed if not x is equal to 0. * / 6 / * Executed if x is not equal to 0. * / 7 8 if (x != y) 9 c(); / * Executed if x is not equal to y. * / 10 else 11 d(); / * Executed if x is not equal to y is not true. * / The possible on linguistic impact of the ! operator on expression comprehension is discussed elsewhere. ! operand type 1103 Cg 1740.2 The top-level operator in the controlling expression of an if statement shall not be ! or != when that statement also contains an else arm. If the value of the controlling expression is known a translation time, the selection statement may contain dead code and the controlling expression is redundant. These issues are discussed elsewhere. dead code 190 redun- dant code 190 Usage In the translated form of this book’s benchmark programs 1.3% of selection-statement s and 4% of iteration-statement s have a controlling expression that is a constant expression. Use of simple, non- iterative, flow analysis enables a further 0.6% of all controlling expressions to be evaluated to a constant expression at translation time. 1741 A selection statement is a block whose scope is a strict subset of the scope of its enclosing block.block selection state- ment Commentary Rationale enum {a, b}; int different(void) { if (sizeof(enum {b, a}) != sizeof(int)) return a; // a == 1 return b; // which b? } In C89, the declaration enum {b, a} persists after the if-statement terminates; but in C99, the implied block that encloses the entire if statement limits the scope of that declaration; therefore the different function returns different values in C89 and C99. The Committee views such cases as unintended artifacts of allowing declarations as operands of cast and sizeof operators; and this change is not viewed as a serious problem. See the following C sentence for a further discussion on the rationale. block selection sub- statement 1742 v 1.2 June 24, 2009 6.8.4 Selection statements 1742 C90 See Commentary. C ++ The C ++ behavior is the same as C90. See Commentary. Coding Guidelines Developers are more likely to be tripped up by the lifetime issues associated with compound literals than enumeration constants. For instance in: 1 if (f(p=&(struct S){1, 2})) 2 / * . * / 3 val=p->mem_1; the lifetime of the storage whose address is assigned to p ends when the execution of the if statement terminates. Ensuring that developers are aware of this behavior is an educational issue. However, developers intentionally relying on the pointed-to storage continuing to exist (which it is likely to, at least until storage needs to be allocated to another object) is a potential guideline issue. However, until experience has been gained on how developers use compound literals it is not known whether this issue is simply an interesting theoretical idea of a real practical problem. 1742 Each associated substatement is also a block whose scope is a strict subset of the scope of the selection block selection sub- statement statement. Commentary Rationale A new feature of C99: A common coding practice is always to use compound statements for every selection and iteration statement because this guards against inadvertent problems when changes are made in the future. Because this can lead to surprising behavior in connection with certain uses of compound literals (§6.5.2.5), the concept of a block has been expanded in C99. Given the following example involving three different compound literals: extern void fn(int * , int * ); int examp(int i, int j) { int * p, * q; if ( * (q = (int[2]){i, j})) fn(p = (int[5]){9, 8, 7, 6, 5}, q); else fn(p = (int[5]){4, 3, 2, 1, 0}, q + 1); return * p; } it seemed surprising that just introducing compound statements also introduced undefined behavior: extern void fn(int * , int * ); int examp(int i, int j) { int * p, * q; June 24, 2009 v 1.2 6.8.4 Selection statements 1742 if ( * (q = (int[2]){i, j})) { fn(p = (int[5]){9, 8, 7, 6, 5}, q); } else { fn(p = (int[5]){4, 3, 2, 1, 0}, q + 1); } return * p; // undefined--no guarantee * p designates an object } Therefore, the substatements associated with all selection and iteration statements are now defined to be blocks, even if they are not also compound statements. A compound statement remains a block, but is no longer the only kind of block. Furthermore, all selection and iteration statements themselves are also blocks, implying no guarantee that * q in the previous example designates an object, since the above example behaves as if written: extern void fn(int * , int * ); int examp(int i, int j) { int * p, * q; { if ( * (q = (int[2]){i, j})) { // * q is guaranteed to designate an object fn(p = (int[5]){9, 8, 7, 6, 5}, q); } else { // * q is guaranteed to designate an object fn(p = (int[5]){4, 3, 2, 1, 0}, q + 1); } } // * q is not guaranteed to designate an object return * p; // * p is not guaranteed to designate an object } If compound literals are defined in selection or iteration statements, their lifetimes are limited to the implied enclosing block; therefore the definition of “block” has been moved to this section. This change is compatible with similar C ++ rules. C90 The following example illustrates the rather unusual combination of circumstances needed for the specification change, introduced in C99, to result in a change of behavior. 1 extern void f(int); 2 enum {a, b} glob; 3 4 int different(void) 5 { 6 if (glob == a) 7 / * No braces. * / 8 f((enum {b, a})1); / * Declare identifiers with same name and compatible type. * / 9 10 return b; / * C90: numeric value 1 * / 11 / * C99: numeric value 0 * / 12 } v 1.2 June 24, 2009 6.8.4.1 The if statement 1742 C ++ The C ++ behavior is the same as C90. Coding Guidelines Some coding guideline documents recommend that the block associated with both selection and iteration using braces block statements always be bracketed with braces (i.e., that it is always a compound statement). When the 1729 compound statement syntax compound statement contains a single statement the use of braces is redundant and their presence decreases the amount of information visible on a display (the number of available lines is fixed and each brace usually occupies one line). However, experience has shown that in some cases the presence of these braces can: • Provide additional visual cues that can reduce the effort needed, by readers, to comprehend a sequence of statements. However, the presence of these redundant braces reduces the total amount of information immediately visible, to a reader, on a single display (i.e., the amount of source code that can be seen without expending motor effort giving editor commands to change the display contents). The way in 0 cost/accuracy trade-off which these costs and benefits trade-off against each other is not known. • Help prevent faults being introduced when code is modified (i.e., where a modification results in unintended changes to the syntactic bindings of blocks to statement headers). Experience shows that 1707 statement header nested if statements are the most common construct whose modification results in unintended changes to the syntactic bindings of blocks. In the following example the presence of braces provides both visual cues that the else does not bind to the outer if and additional evidence (its indentation provides counter evidence because it provides an interpretation that the intent is to bind to the outer if) that it is intended to bind to the inner if. 1 void f(int i) 2 { 3 if (i > 8) 4 if (i < 20) 5 i++; 6 else 7 i--; 8 9 if (i > 8) 10 { 11 if (i < 20) 12 i++; 13 else 14 i--; 15 } 16 } Blocks occur in a number of statements, is there a worthwhile cost/benefit in guideline recommendation specifying that these blocks always be a compound statement? The block associated with a switch statement is invariably a compound statement. A guideline recom- mendation that braces be used is very likely to be redundant in this case. Iteration statements are not as common as selection statements and much less likely to be nested (in other iteration statements) than selection statements (compare Figure 1739.2 and Figure 1763.2), and experience suggests developer comprehension of such constructs is significantly affected by the use of braces. Experience suggests that the nested if statement is the only construct where the benefit of the use of braces is usually greater than the cost. Cg 1742.1 The statement forming the block associated with either arm of an if statement shall not be an if statement. June 24, 2009 v 1.2 6.8.4.1 The if statement 1743 6.8.4.1 The if statement Constraints 1743 The controlling expression of an if statement shall have scalar type.if statement controlling ex- pression scalar type Commentary Although the type _Bool was introduced in C99 the Committee decided that there was too much existing code to change the specification for the controlling expression type. C ++ 6.4p4 The value of a condition that is an expression is the value of the expression, implicitly converted to bool for statements other than switch; if that conversion is ill-formed, the program is ill-formed. If only constructs that are available in C are used the set of possible expressions is the same. Other Languages In many languages the controlling expression is required to have a boolean type. Languages whose design has been influenced by C often allow the controlling expression to have scalar type. Coding Guidelines The broader contexts in which readers need to comprehend controlling expression are discussed elsewhere. selection statement syntax 1739 This subsection concentrates on the form of the controlling expression. The value of a controlling expression is used to make one of two choices. Values used in this way are generally considered to have a boolean role. Some languages require the controlling expression to have a boolean type and their translators enforce this requirement. Some coding guideline documents contain recommendations that effectively try to duplicate this boolean type requirement found in other languages. Recommendations based on type not only faces technical problems in their wording and implementation (caused by the implicit promotions and conversions performed in C), but also fail to address the real issues of developer comprehension and performance. In the context of an if statement do readers of the source distinguish between expressions that have two possible values (i.e., boolean roles), and expressions that may have more than two values being used in a context where an implicit test against zero is performed? Is the consideration of boolean roles a cultural baggage carried over to C by developers who have previously used them in other languages? Do readers who have only ever programmed in C make use of boolean roles, or do they think in terms of a test against zero? In the absence of studies of developer mental representations of algorithmic and source code constructs, it is not possible to reliably answer these questions. Instead the following discussion looks at the main issues involved in making use of boolean roles and making use of the implicit a test against zero special case. A boolean role is not about the type of an expression (prior to the introduction of the type _Bool in C99, a character type was often used as a stand-in), but about the possible values an expression may have and how they are used. The following discussion applies whether a controlling expression has an integer, floating, or pointer type. In some cases the top-level operator of a controlling expression returns a result that is either zero or one (e.g., the relational and equality operators). The visibility, in the source, of such an operator signals its boolean role to readers. However, in other cases (see Table 1763.2) developers write controlling expressions that do not contain explicit comparisons (the value of a controlling expression is implicitly compared against zero). What are the costs and benefits of omitting an explicit comparison? The following code fragment contains examples of various ways of writing a controlling expression: 1 if (flag) / * 1 * / 2 / * . * / v 1.2 June 24, 2009 6.8.4.1 The if statement 1743 3 4 if (int_value) / * 2 * / 5 / * . * / 6 7 if (flag == TRUE) / * 3 * / 8 / * . * / 9 10 if (int_value != 0) / * 4 * / 11 / * . * / Does the presence of an explicit visual (rather than an implicit, in the developers mind) comparison reduce either the cognitive effort needed to comprehend the if statement or the likelihood of readers making mistakes? Given sufficient practice readers can learn to automatically process if (x) as if it had been written as if (x != 0) . The amount of practice needed to attain an automatic level of performance is unknown. Another unknown is the extent to which the token sequence != 0 acts as a visual memory aid. When the visible form of the controlling expression is denoted by a single object (which may be an ordinary identifier, or the member of a structure, or some other construct where a value is obtained from an object) that name may provide information on the values it represents. To obtain this information readers might make use of the following: • Software development conventions. In the software development community (and other communities) the term flag is generally understood to refer to something that can be in one of two states. For instance, the identifier mimbo_flag is likely to be interpreted as having two possible values relating to a mimbo, rather than referring to the national flag of Mimbo. Some naming conventions contain a greater degree of uncertainty than others. For instance, identifiers whose names contain the character sequence status sometimes represent more than two values. • Natural language knowledge. Speakers of English regard some prepositions as being capable of representing two states. For instance, a cat is or is not black. This natural language usage is often adopted when selecting identifier names. For instance, is_flobber is likely to be interpreted as representing one of two states (being a, or having the attribute of, flobber or not). • Real world knowledge. A program sometimes needs to take account of information from the real world. For instance, height above the ground is an important piece of information in an airplane flight simulator, with zero height having a special status. • Application knowledge. The design of a program invariably makes use of knowledge about the application domain it operates within. For instance, the term ziffer may be used within the application domain that a program is intended to operate. Readers of the source will need the appropriate application knowledge to interpret the role of this identifier. • Program implementation conventions. The design of a program involves creating and using various conventions. For instance, a program dealing with book printing may perform special processing for books that don’t contain any pages (e.g., num_pages being zero is a special case). • Conventions and knowledge from different may be mixed together. For instance, the identifier name current_color suggests that it represents color information. This kind of information is not usually thought about in terms of numeric values and there are certainly more than two colors. However, assigning values to symbolic qualities is a common software development convention, as is assigning a special interpretation to certain values (e.g., using zero to represent no known color, a program implementation convention). The likelihood of a reader assuming that an identifier name has a boolean role will depend on the cultural beliefs and conventions they share with the author of the source. There is also the possibility that rather than using the identifier name to deduce a boolean role, readers may use the context in which it occurs to infer a 476 boolean role boolean role. This is an example of trust based usage. Requiring that values always be compared (against 792 trust based usage true/false or zero/nonzero) leads to infinite regression, as in the sequence: June 24, 2009 v 1.2 6.8.4.1 The if statement 1746 1 if (flag) 2 if (flag == TRUE) 3 if ((flag == TRUE) == TRUE) 4 and so on . At some point readers have to make a final comparison in their own mind. The inability to calculate (i.e., automatically enforceable) the form a controlling expression should take to minimize readers cognitive effort prevents any guideline recommendations being made here. Semantics 1744 In both forms, the first substatement is executed if the expression compares unequal to 0.if statement operand compare against 0 Commentary Depending on the type of the other operand this 0 may be converted to an integer type of greater rank, a floating-point 0.0, or a null pointer constant. null pointer constant 748 C ++ The C ++ Standard expresses this behavior in terms of true and false (6.4.1p1). The effect is the same. Other Languages In languages that support a boolean type this test is usually expressed in terms of true and false. Common Implementations The machine code generation issues are similar to those that apply to the logical operators. The degree to logical negation result is 1111 && operand com- pare against 0 1250 which this comparison can be optimized away depends on the form of the controlling expression and the processor instruction set. If the controlling expressions top-level operator is one that always returns a value of zero or one (e.g., an equality or relational operator), it is possible to generate machine code that performs a branch rather than returning a value that is then compared. Some processors have a single instruction that performs a comparison and branch, while others have separate instructions (the comparison instruction setting processor condition flags that are then tested by a conditional branch instruction). On some processors simply loading a value into a register also results in a comparison against zero being made, with the appropriate processor condition flags being set. The use of conditional instructions is discussed elsewhere. conditional instructions 1739 The machine code for the first substatement is often placed immediately after the code to evaluate the controlling expression. However, optimizers may reorder blocks of code in an attempt to maximize instruction basic block 1710 cache utilization. 1745 In the else form, the second substatement is executed if the expression compares equal to 0.else Commentary Implementations are required to ensure that exactly one of the equality comparisons is true. equality operators exactly one relation is true 1221 Coding Guidelines Some coding guideline documents recommend that the else form always be present, even if it contains no executable statements. Such a recommendation has the benefit of ensuring that there are never any mismatching if / else pairs. However, then the same effect can be achieved by requiring nested if statements to be enclosed in braces (this issue is discussed elsewhere). The cost of adding empty else forms increases using braces block 1742 the amount of source code that may need to be read and in some cases decrease in the amount of non-null source that appears on a display device. Such a guideline recommendation does not appear worthwhile. Usage In the visible form of the .c files 21.5% of if statements have an else form. (Counting all forms of if supported by the preprocessor, with #elif counting as both an if and an else, there is an #else form in 25.0% of cases.) v 1.2 June 24, 2009 6.8.4.2 The switch statement 1748 1746 If the first substatement is reached via a label, the second substatement is not executed. Commentary The flow of control of a sequence of statements is not influenced by how they were initially reached, in the flow of control. The label may be reached as a result of executing a switch statement, or a goto statement. 1753 switch statement causes jump 1789 goto causes uncon- ditional jump The issue of jumping into nested blocks or the body of iteration statements is discussed elsewhere. 1783 jump state- ment causes jump to 1766 iteration statement executed repeat- edly C ++ The C ++ Standard does not explicitly specify the behavior for this case. Other Languages This statement applies to all programming languages that support jumps into more deeply nested blocks. 1747 An else is associated with the lexically nearest preceding if that is allowed by the syntax. else binds to nearest if Commentary As it appears in the standard the syntax for if statements is ambiguous on how an else should be associated 1739 selection statement syntax in a nested if statement. This semantic rule resolves this ambiguity. Other Languages Languages that support nesting of conditional statements need a method of resolving which construct an else binds to. The rules used include the following: • Not supporting in the language syntax unbracketed nesting (i.e., requiring braces or begin / end pairs) within the then arm. For instance, Algol 60 permits the usage IF q1 THEN a1 ELSE IF q2 THEN a2 ELSE a3 , but the following is a syntax violation IF q1 THEN IF q2 THEN a1 ELSE a2 ELSE a3. • Using a matching token to pair with the if . The keyword fi is a common choice (used by Ada, Algol 68, while the C preprocessor uses endif ). In this case the bracketing formed by the if / fi prevents any ambiguity occurring. • Like C— using the nearest preceding rule. Coding Guidelines If the guideline recommendation on using braces is followed there will only ever be one lexically preceding 1742.1 if statement block not an if statement if that an else can be associated with. Some coding guideline documents recommend that an if statement always have an associated else form, even if it only contains the null statement. 1733 null state- ment 6.8.4.2 The switch statement Constraints 1748 The controlling expression of a switch statement shall have integer type. switch statement Commentary A switch statement uses the exact value of its controlling expression and it is not possible to guarantee the exact value of an expression having a floating type (there is a degree of unpredictability in the value between different implementations). For this reason implementations are not required to support controlling expressions having a floating type. C ++ 6.4.2p2 June 24, 2009 v 1.2 6.8.4.2 The switch statement 1749 The condition shall be of integral type, enumeration type, or of a class type for which a single conversion function to integral or enumeration type exists (12.3). If only constructs that are available in C are used the set of possible expressions is the same. Common Implementations The base document did not support the types long and unsigned long . Support for integer types with rank greater than int was added during the early evolution of C. [1199] Other Languages There are some relatively modern languages (e.g., Perl) that do not support a switch statement. Java does not support controlling expressions having type long . Some languages (e.g., PHP) support controlling expressions having a string type. Coding Guidelines A controlling expression, in a switch statement, having a boolean role might be thought to be unusual, an if statement being considered more appropriate. However, the designer may be expecting the type of the controlling expression to evolve to a non-boolean role, or the switch statement may have once contained more case labels. Table 1748.1: Occurrence of switch statements having a controlling expression of the given type (as a percentage of all switch statements). Based on the translated form of this book’s benchmark programs. Type % Type % int 29.5 bit-field 3.1 unsigned long 18.7 unsigned short 2.8 enum 14.6 short 2.5 unsigned char 12.4 long 0.9 unsigned int 10.0 other-types 0.2 char 5.1 1749 If a switch statement has an associated case or default label within the scope of an identifier with a variably switch past variably modified type modified type, the entire switch statement shall be within the scope of that identifier. 133) case value density switch statements 0 20 40 60 80 100 1 10 100 1,000 • no default × with default ∆ embedded • • • • • • • • • • • • • • • • • • • • • • • • • • × × × × × × × × × × × × × × × × × × × × × × × × × × ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ ∆ case value span 1 10 100 1000 • • •• • • • • •• • • • • •• • • •• • • • • • •• • • • • •• • • • • • • • •• • • • • ••• • • ••• • • • • •• •• •• • • • • • • • • • • • • • •• • • • • • • • • • ••• • •• • • •• • • • • • • • •••• • • • • ••• •• •• • • × × × × ×× × × × × ×× × × ×× × × × × × × × × × × × × ×× × × × × × × × × × × ××× × ×× × ×× × × × × × × × × × × × ×× × × ××× × × × ×× ××× × × × × ×× × ××× × ×× × × × × × × × × × × × × × × × × × ×× × × × × × × ×× × × × × × × ×× × × × ×× × × × × × × × × × × × × × × × ×× × × × × × × × × × × × × × × × × × × × × × × × × × × × ×× × × × × × × × × × × × × × × × × × × × × ×× × × × × × ×× ×× × × ×× × × × × × × × × × ××× × × × × × × × × Figure 1748.1: Density of case label values (calculated as (maximum case label value minus minimum case label value minus one) divided by the number of case labels associated with a switch statement) and span of case label values (calculated as (maximum case label value minus minimum case label value minus one)). Based on the translated form of this book’s benchmark programs and embedded results from Engblom [397] (which were scaled, i.e., multiplied by a constant, to allow comparison). The no default results were scaled so that the total count of switch statements matched those that included a default label. v 1.2 June 24, 2009 [...]... end-of-file character, rather than an integer constant) There does not appear to be a worthwhile benefit in having a deviation that permits the use of the integer constant 0 rather than the character constant ’\0’, on the grounds of improved reader recognition performance The character constant ’\0’ is the most commonly occurring character constant (10% of all character constants in the visible form of the c. .. the declaration either precedes the switch statement, or it follows the last case or default label footnote 133 associated with the switch that is in the block containing the declaration Commentary If the declaration is not followed by any case or default labels, all references to the identifier it declares can only occur in the statements that follow it (which can only be reached via a jump to preceding... jumps to the statement 1757 following the matched case label Commentary A case label can appear on any statement in the switch body 1 2 3 4 5 6 7 Duff’s Device 1766 switch (x) default : if (prime(x)) case 2: case 3: case 5: case 7: process_prime(x); else case 4: case 6: case 8: case 10: process_composite(x); There can be more practical uses for this functionality Coding Guidelines Experience suggests... this specification is the same as that given for the block implicitly created for a selection statement The loop body is also a block whose scope is a strict subset of the scope of the iteration statement block loop body 1769 Commentary block 1742 selection substatement The rationale for this specification is the same as that given for the block implicitly created for the substatements of a selection statement... the pipeline and the following instruction is already in the pipeline behind it Until the processor executes the branch instruction it does not know which location to fetch the next instruction from, a pipeline stall has occurred Branch instructions are relatively common, which means that pipeline stalls can have a significant performance impact The main techniques used by processor vendors to reduce... (because of the comparatively poor performance 0 translator of translator generated machine code) is that addressed by DSP processors, which often contain such performance vs assembler [989] decrement (and/or increment) branch instructions (the SC140 DSP core includes hardware loop 0 DSP processors counters that support up to four levels of loop nesting) The C compiler for the Unisys e-@ction Application... special case The constant expression in each case label is converted to the promoted type of the controlling expression 1756 Commentary Prior to this conversion the type of the constant expression associated with each case label is derived from the form of the literals and result type of the operators it contains The relationship between the value of a case label and a controlling expression is not the. .. statements (or rather the machine code generated to implement them) disrupt the smooth flow of instructions into the pipeline This disruption occurs because the instruction fetch unit assumes the next instruction executed will the one following the current instruction, the processor is not aware it has encountered a branch instruction until that instruction has been decoded, by which time it is one or more... register) Because of their small size (the Agere DSP16000[6] loop buffer has a limit of 31 instructions) and restrictions on instructions that may be executed (e.g., no instructions that change the flow of control) optimizers can have difficulty making good of such buffers.[1419] 988 0 data dependency cache The characteristics of loop usage often means that successive array elements are accessed on successive... selection, or purely a class exercise to practice the using a language construct) to use a particular construction to perform some operation Reuse of the same construction to perform the same, or similar operations leads to it becoming established as part of their repertoire The pattern of usage seen in source code being the sum of individual habits In both cases the choice of for/while involves a process . type Commentary Although the type _Bool was introduced in C9 9 the Committee decided that there was too much existing code to change the specification for the. permits the use of the integer constant 0 rather than the character constant ’’ , on the grounds of improved reader recognition performance. The character constant