Conditional constructsFrom Wikipedia, the free encyclopedia

Contents

1 ?: 11.1 Conditional assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 ActionScript 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 ALGOL 68 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.5 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.6 CFML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.7 CoeeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.8 Common Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.9 Delphi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.10 Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.11 Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.12 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.13 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.14 Lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.15 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.16 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.17 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.18 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.19 R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.20 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.21 TestStand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.22 Visual Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Result type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 ?: in style guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.2 Case selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Programming languages without the conditional operator . . . . . . . . . . . . . . . . . . . . . . 111.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

i

ii CONTENTS

1.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Anankastic conditional 132.1 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Antecedent (logic) 143.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Arithmetic IF 154.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Assertion (software development) 165.1 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.1 Assertions in design by contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.2 Assertions for run-time checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.3 Assertions during the development cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.4 Assertions in production environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.5 Static assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Disabling assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4 Comparison with error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Branch predication 216.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.4 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.7 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 Branch table 247.1 Typical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.2 Alternative implementation using addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.3 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.5 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

CONTENTS iii

7.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.7 Jump table example in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.8 Jump table example in PL/I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.9 Compiler generated branch tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.9.1 Computed GoTo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.10 Creating the index for the branch table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.11 Other uses of technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.12 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.13 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.14 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Causality 298.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.1.1 Western philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308.1.2 Hindu philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.1.3 Buddhist philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.2 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2.1 Necessary and sucient causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2.2 Causality contrasted with conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2.3 Questionable cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.3 Theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348.3.1 Counterfactual theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.3.2 Probabilistic causation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.3.3 Causal calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.3.4 Structure learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.3.5 Derivation theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.3.6 Manipulation theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.3.7 Process theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.3.8 Systemic causality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.4 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.4.1 Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.4.2 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.4.3 Humanities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.4.4 Theology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.7 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9 Chunklet 469.1 Embedded Chunklets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

iv CONTENTS

10 If-else-if ladder 4710.1 Ifthen(else) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

10.1.1 Else if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4810.1.2 If-then-else expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4810.1.3 Arithmetic if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4910.1.4 Object-oriented implementation in Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . 50

10.2 Case and switch statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5010.3 Pattern matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5010.4 Hash-based conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5010.5 Branch predication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.6 Choice system cross reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

11 Conditional mood 5311.1 Germanic languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

11.1.1 English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5311.1.2 German . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5411.1.3 Dutch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

11.2 Romance languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5411.2.1 Romanian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

11.3 Slavic languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5511.3.1 Russian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5511.3.2 Polish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

11.4 Uralic languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5611.4.1 Hungarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5611.4.2 Finnish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

11.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5611.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

12 Conditional perfect 5812.1 English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5812.2 Other languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5812.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5912.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

13 Conditional probability 6013.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

13.1.1 Conditioning on an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6013.1.2 Denition with -algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6213.1.3 Conditioning on a random variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

CONTENTS v

13.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6313.3 Use in inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6413.4 Statistical independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6413.5 Common fallacies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

13.5.1 Assuming conditional probability is of similar size to its inverse . . . . . . . . . . . . . . . 6513.5.2 Assuming marginal and conditional probabilities are of similar size . . . . . . . . . . . . . 6513.5.3 Over- or under-weighting priors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

13.6 Formal derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6613.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6613.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6713.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

14 Conditional probability table 6814.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

15 Conditional proof 6915.1 Symbolic logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6915.2 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6915.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

16 Conditional sentence 7016.1 Types of conditional sentence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

16.1.1 Implicative and predictive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7016.1.2 Counterfactual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

16.2 Grammar of conditional sentences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7116.2.1 English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7116.2.2 Latin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7316.2.3 French . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7316.2.4 Italian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7416.2.5 Slavic languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

16.3 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7416.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7416.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7416.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

17 Consequent 7617.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7617.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

18 Control break 77

19 Corresponding conditional 7819.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7819.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

vi CONTENTS

19.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7919.4 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7919.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

20 Counterfactual conditional 8120.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8120.2 Reversal of clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8220.3 Psychology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

20.3.1 Comprehension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8220.3.2 Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8220.3.3 Psychological accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

20.4 Philosophical treatments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8220.4.1 Connective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8320.4.2 Possible world semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8320.4.3 Other accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8420.4.4 Within empirical testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

20.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8420.6 Footnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8520.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

21 Elvis operator 8821.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8821.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8821.3 Groovy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8921.4 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8921.5 Related expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8921.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8921.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

22 English conditional sentences 9122.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9122.2 English language teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

22.2.1 Zero conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9222.2.2 First conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9222.2.3 Second conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9322.2.4 Third conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9422.2.5 Mixed conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

22.3 Use of will and would in condition clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9522.4 Inversion in condition clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9622.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

23 Guard (computer science) 9823.1 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

CONTENTS vii

23.2 Pattern guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9923.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9923.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

24 If-else-if ladder 10024.1 Ifthen(else) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

24.1.1 Else if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10124.1.2 If-then-else expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10124.1.3 Arithmetic if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10224.1.4 Object-oriented implementation in Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . 103

24.2 Case and switch statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10324.3 Pattern matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10324.4 Hash-based conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10324.5 Branch predication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10424.6 Choice system cross reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10424.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10424.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10424.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

25 IIf 10625.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10625.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10625.3 Criticisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

25.3.1 Eciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10625.3.2 Side Eects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

25.4 Alternatives to IIf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10725.5 IIf in other programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10725.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10825.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

26 Implication 10926.1 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10926.2 Linguistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10926.3 Other uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10926.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

27 Implicational propositional calculus 11027.1 Virtual completeness as an operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11027.2 Axiom system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11027.3 Basic properties of derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11127.4 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

27.4.1 Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11127.5 The BernaysTarski axiom system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

viii CONTENTS

27.6 Testing whether a formula of the implicational propositional calculus is a tautology . . . . . . . . . 11327.7 Adding an axiom schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11427.8 An alternative axiomatization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11427.9 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11627.10References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

28 Indicative conditional 11728.1 Distinctions between the material conditional and the indicative conditional . . . . . . . . . . . . . 11728.2 Psychology and indicative conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11728.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11728.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11828.5 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

29 Material conditional 11929.1 Denitions of the material conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

29.1.1 As a truth function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12029.1.2 As a formal connective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

29.2 Formal properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12129.3 Philosophical problems with material conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . 12129.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

29.4.1 Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12229.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12229.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12229.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

30 Multiway branch 12430.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12430.2 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12430.3 Quotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12530.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12530.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12530.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

31 Necessity and suciency 12631.1 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12631.2 Necessity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12631.3 Suciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12831.4 Relationship between necessity and suciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12931.5 Simultaneous necessity and suciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12931.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

31.6.1 Argument forms involving necessary and sucient conditions . . . . . . . . . . . . . . . . 13031.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13031.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

CONTENTS ix

32 Null coalescing operator 13132.1 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13132.2 CFML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13132.3 Clojure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13232.4 F# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13232.5 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13232.6 Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13232.7 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13332.8 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13332.9 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13332.10Kotlin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13332.11Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13432.12See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13432.13References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

33 Pattern matching 13533.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13533.2 Primitive patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13533.3 Tree patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13633.4 Filtering data with patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13633.5 Pattern matching in Mathematica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

33.5.1 Declarative programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13733.6 Pattern matching and strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

33.6.1 Tree patterns for strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13833.6.2 Example string patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13833.6.3 SNOBOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

33.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13933.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14033.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

34 Strict conditional 14134.1 Avoiding paradoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14134.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14134.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14234.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14234.5 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

35 Switch statement 14435.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14435.2 Typical syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14435.3 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

35.3.1 Fallthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

x CONTENTS

35.4 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14535.5 Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14635.6 Alternative uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

35.6.1 Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14735.7 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14735.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14735.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14735.10Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

36 test (Unix) 14936.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14936.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14936.3 Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

36.3.1 String arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15036.3.2 Number arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15036.3.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

36.4 Exit Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15036.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15036.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15036.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

37 Three-way comparison 15237.1 Machine-level computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15237.2 High-level languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

37.2.1 Composite data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15337.3 Trivia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15337.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15337.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

38 Truth bit 15438.1 Memory usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15438.2 Eciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15438.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15438.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15438.5 Text and image sources, contributors, and licenses . . . . . . . . . . . . . . . . . . . . . . . . . . 155

38.5.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15538.5.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15938.5.3 Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Chapter 1

?:

This article is about the use of the ?: operator as a ternary operator. For use as a binary operator, see Elvisoperator.

In computer programming, ?: is a ternary operator that is part of the syntax for a basic conditional expression inseveral programming languages. It is commonly referred to as the conditional operator, inline if (iif), or ternaryif.It originally comes from CPL, in which equivalent syntax for e1 ? e2 : e3 was e1 e2, e3.[1][2]

Although many ternary operators are possible, the conditional operator is so common, and other ternary operators sorare, that the conditional operator is commonly referred to as the ternary operator.

1.1 Conditional assignment?: is used as follows:

condition ? value_if_true : value_if_false

The condition is evaluated true or false as a Boolean expression. On the basis of the evaluation of the Booleancondition, the entire expression returns value_if_true if condition is true, but value_if_false otherwise. Usually thetwo sub-expressions value_if_true and value_if_false must have the same type, which determines the type of thewhole expression. The importance of this type-checking lies in the operators most common usein conditionalassignment statements. In this usage it appears as an expression on the right side of an assignment statement, asfollows:

variable = condition ? value_if_true : value_if_false

The ?: operator is similar to the way conditional expressions (if-then-else constructs) work in functional programminglanguages, like Scheme, ML, and Haskell, since if-then-else forms an expression instead of a statement in thoselanguages.

1.2 UsageThe conditional operators most common usage is to make a terse simple conditional assignment statement. Forexample, if we wish to implement some C code to change a shops opening hours from 9 o'clock during weekdays to12 o'clock on weekends, we may useint opening_time = (day == WEEKEND) ? 12 : 9;

instead of the more verbose

1

2 CHAPTER 1. ?:

int opening_time; if (day == WEEKEND) opening_time = 12; else opening_time = 9;

The two forms are nearly equivalent. Keep in mind that the ?: is an expression and if-then-else is a statement. Notethat neither the true nor false portions can be omitted from the conditional operator without an error report uponparsing. This contrasts with if-then-else statements, where the else clause can be omitted.Most of the languages emphasizing functional programming don't need such an operator as their regular conditionalexpression(s) is an expression in the rst place e.g. the Scheme expression (if (> a b) a b) is equivalent in semanticsto the C expression (a > b) ? a : b. This is also the case in many imperative languages, starting with ALGOL whereit is possible to write result := if a > b then a else b, or Smalltalk (result := (a > b) ifTrue: [ a ] ifFalse: [ b ]) or Ruby(result = if a > b then a else b end, although result = a > b ? a : b works as well).Note that some languages may evaluate 'both' the true- and false-expressions, even though only one or the other willbe assigned to the variable. This means that if the true- or false-expression contain a function call, that function maybe called and executed (causing any related side-eects due to the functions execution), regardless of whether ornot its result will be used. Programmers should consult their programming language specications or test the ternaryoperator to determine whether or not the language will evaluate both expressions in this way. If it does, and this isnot the desired behaviour, then an if-then-else statement should be used.

1.2.1 ActionScript 3condition ? value_if_true : value_if_false

1.2.2 ALGOL 68Both ALGOL 68's choice clauses (if and the case clauses) provide the coder with a choice of either the "bold" syntaxor the "brief" form.

Single if choice clause:

if condition then statements [ else statements ] "brief" form: ( condition | statements | statements )

Chained if choice clause:

if condition1 then statements elif condition2 then statements [ else statements ] "brief" form: ( condition1 |statements |: condition2 | statements | statements )

1.2.3 CA traditional if-else construct in C, Java and JavaScript is written:[3]

if (a > b) { result = x; } else { result = y; }

This can be rewritten as the following statement:result = a > b ? x : y;

As in the if-else construct only one of the expressions 'x' and 'y' is evaluated. This is signicant if the evaluation of 'x'or 'y' has side eects.[4] The behaviour is undened if an attempt is made to use the result of the conditional operatoras an lvalue.[4]

A GNU extension to C allows omitting the second operand, and using implicitly the rst operand as the second also:a = x ? : y;

The expression is equivalent to

1.2. USAGE 3

a = x ? x : y;

except that if x is an expression, it is evaluated only once. The dierence is signicant if evaluating the expressionhas side eects. This shorthand form is sometimes known as the Elvis operator in other languages.

1.2.4 C++In C++ there are conditional assignment situations where use of the if-else statement is impossible, since this languageexplicitly distinguishes between initialization and assignment. In such case it is always possible to use a function call,but this can be cumbersome and inelegant. For example, to pass conditionally dierent values as an argument fora constructor of a eld or a base class, it is impossible to use a plain if-else statement; in this case we can use aconditional assignment expression, or a function call. Bear in mind also that some types allow initialization, but donot allow assignment, or even that the assignment operator and the constructor do totally dierent things. This last istrue for reference types, for example:#include #include #include intmain(int argc, char *argv[]) { std::string name; std::ofstreamfout; if (argc > 1 && argv[1]) { name = argv[1]; fout.open(name.c_str(), std::ios::out | std::ios::app); } std::ostream&sout = name.empty() ? std::cout : fout; sout

4 CHAPTER 1. ?:

result = f() ?: default"; // where... function f(){ if (randRange(0,1)){ // either 0 or 1 (false / true) return value"; }} writeOutput(result);

The function f() will return value roughly 50% of the time, otherwise will not return anything. If f() returns value,result will take that value, otherwise will take the value default.

1.2.7 CoeeScript

Example of using this operator in CoeeScript:if 1 is 2 then true value else false value

Returns false value.

1.2.8 Common Lisp

Assignment using a conditional expression in Common Lisp:(setf result (if (> a b) x y))

Alternative form:(if (> a b) (setf result x) (setf result y))

1.2.9 Delphi

In Delphi the IfThen function can be used to achieve the same as ?:. If the System.Math library is used, the IfThenfunction returns a numeric value such as an Integer, Double or Extended. If the System.StrUtils library is used, thisfunction can also return a string value.Using System.Mathfunction IfThen(AValue: Boolean; const ATrue: Integer; const AFalse: Integer): Integer; function IfThen(AValue:Boolean; const ATrue: Int64; const AFalse: Int64): Int64; function IfThen(AValue: Boolean; const ATrue: UInt64;const AFalse: UInt64): UInt64; function IfThen(AValue: Boolean; const ATrue: Single; const AFalse: Single): Sin-gle; function IfThen(AValue: Boolean; const ATrue: Double; const AFalse: Double): Double; function IfThen(AValue:Boolean; const ATrue: Extended; const AFalse: Extended): Extended;

Using the System.StrUtils libraryfunction IfThen(AValue: Boolean; const ATrue: string; AFalse: string = ''): string;

Usage example:function GetOpeningTime(Weekday: Integer): Integer; begin { This function will return the opening time for thegiven weekday: 12 for weekends, 9 for other days } Result := IfThen((Weekday = 1) or (Weekday = 7), 12, 9); end;

Unlike a true ternary operator however, both of the results are evaluated prior to performing the comparison. Forexample, if one of the results is a call to a function which inserts a row into a database table, that function will becalled whether or not the condition to return that specic result is met.

1.2.10 Fortran

With the additions to the code in the 1995 release, the ternary operator was added to the Fortran compiler as theintrinsic functionmerge:

1.2. USAGE 5

variable = merge(x,y,a>b)

1.2.11 HaskellThe built-in if-then-else syntax is inline: the expressionif predicate then expr1 else expr2

has typeBool -> a -> a -> a

The base library also provides the function Data.Bool.bool:bool :: a -> a -> Bool -> a

In both cases, no special treatment is needed to ensure that only the selected expression is evaluated, since Haskell isnon-strict by default.

1.2.12 JavaIn Java this expression evaluates to:If foo is selected, assign selected foo to bar. If not, assign baz to bar.Object bar = foo.isSelected() ? foo : baz;

Note that Java, in a manner similar to C#, only evaluates the used expression and will not evaluate the unusedexpression.[5]

1.2.13 JavaScriptThe conditional operator in JavaScript has the same syntax and precedence structure as in the other BCPL-derivedvariants, where the operator return the value of the expression, and never a reference.[6]

var fooNotNull = (foo !== null) ? true : false; var timeout = settings !== null ? settings.timeout : 1000;

Just like C# and Java, the expression will only be evaluated if, and only if, the expression is the matching one for thecondition given; the other expression will not be evaluated.

1.2.14 LuaLua doesn't have a traditional conditional operator. However, the short-circuit behaviour of its and and or oper-ators allows the emulation of this behaviour:-- equivalent to var = cond ? a : b; var = cond and a or b

This will succeed unless a is logically false (false or nil); in this case, the expression will always result in b. Thiscan result in some surprising behaviour if ignored.

1.2.15 SQLMySQL

This syntax is not SQL standard; it is MySQL specic.

6 CHAPTER 1. ?:

IF(cond,a,b);

Oracle SQL

While Oracle doesn't provide an explicit conditional operator, it does have a variadic functional counterpart whichoperates similarly to a switch statement and can be used to emulate the conditional operator when testing for equality(more complicated logic can be encapsulated in a switch statement).-- General syntax takes case-result pairs, comparing against an expression, followed by a fall-back result: DE-CODE(expression, case1, result1, ... caseN, resultN, resultElse) -- We can emulate the conditional operator byjust selecting one case: DECODE(expression, condition, true, false)

The DECODE function is, today, deprecated in favour of Oracles full switch statement, CASE. This can be used inboth Oracle SQL queries as well as PL/SQL blocks, whereas decode can only be used in the former.SELECT (CASE WHEN a > b THEN x ELSE y END) AS Conditional_Example FROM DUAL;

1.2.16 PerlA traditional if-else construct in Perl or PHP is written:if ($a > $b) { $result = $x; } else { $result = $y; }

Rewritten to use the conditional operator:$result = $a > $b ? $x : $y;

Unlike C, perl allows the use of the conditional expression as an Lvalue, e.g.$a > $b ? $x : $y = $result;

will assign '$result' to either '$x' or '$y' depending on the logical expression.

Perl 6

Uses double "?" symbols and double "!" instead of ":"[7]

$result = $a > $b ?? $x !! $y;

1.2.17 PHPA simple PHP implementation is this:

Due to an unfortunate error in the language grammar, the implementation of ?: in PHP uses the incorrect associativitywhen compared to other languages, and given a value of T for arg, the PHP code in the following example wouldyield the value horse instead of train as one might expect:[8]

1.2. USAGE 7

8 CHAPTER 1. ?:

similar results fromfunc = lambda b,a1,a2: a1 if b else a2 func = lambda b,a1,a2: (b and [a1] or [a2])[0] func = lambda b,a1,a2:(lambda:a1, lambda:a2)[not b]()

as the correct call would be>>> func(True, true, false)() true 'truly' >>> func(False, true, false)() false 'falsely'

however the python 2.5 construct is safer; calling the construct directly works more intuitively>>> true() if True else false() true 'truly' >>> true() if False else false() false 'falsely'

clearly the reason being that in the case offunc(True, true(), false())

the functions are called when sent as parameters rather than when returned from func()

1.2.19 R

The traditional if-else construct in R (which is an implementation of S) is:if (a < b) { x

1.3. RESULT TYPE 9

result = a > b ? x : y

1.2.21 TestStandIn a National Instruments TestStand expression, if condition is true, the rst expression is evaluated and becomes theoutput of the conditional operation; if false, the second expression is evaluated and becomes the result. Only one oftwo expressions is ever evaluated.condition ? rst_expression : second_expression

For example:RunState.Root.Parameters.TestSocket.Index == 3 ? Locals.UUTIndex = 3 : Locals.UUTIndex = 0

Sets the UUTIndex local variable to 3 if TestSocket.Index is 3, otherwise it sets UUTIndex to 0.Similar to other languages, rst_expression and second_expression do not need to be autonomous expressions,allowing the operator to be used for variable assignment:Locals.UUTIndex = ( RunState.Root.Parameters.TestSocket.Index == 3 ? 3 : 0 )

1.2.22 Visual BasicVisual Basic doesn't use ?: per se, but has a very similar implementation of this shorthand if...else statement. Usingthe rst example provided in this article, it can do:' variable = IIf(condition, value_if_true, value_if_false) Dim opening_time As Integer = IIf((day = WEEKEND),12, 9)

In the above example, IIf is a ternary function, but not a ternary operator. As a function, the values of all three portionsare evaluated before the function call occurs. This imposed limitations, and in Visual Basic .Net 9.0, released withVisual Studio 2008, an actual conditional operator was introduced, using the If keyword instead of IIf. This allowsthe following example code to work:Dim name As String = If(person Is Nothing, "", person.Name)

Using IIf, person.Name would be evaluated even if person is null (Nothing), causing an exception. With a trueshort-circuiting conditional operator, person.Name is not evaluated unless person is not null.Visual Basic Version 9 has added the operator If() in addition to the existing IIf() function that existed previously.As a true operator, it does not have the side eects and potential ineciencies of the IIf() function.The syntaxes of the tokens are similar: If([condition], op1, op2) vs IIf(condition, op1, op2). As mentioned above,the function call has signicant disadvantages, because the sub-expressions must all be evaluated, according to VisualBasics evaluation strategy for function calls and the result will always be of type variant (VB) or object (VB.NET).The If()operator however does not suer from these problems as it supports conditional evaluation and determinesthe type of the expression based on the types of its operands.

1.3 Result typeClearly the type of the result of the ?: operator must be in some sense the type unication of the types of its secondand third operands. In C this is accomplished for numeric types by arithmetic promotion; since C does not have a typehierarchy for pointer types, pointer operands may only be used if they are of the same type (ignoring type qualiers)or one is void or NULL. It is undened behaviour to mix pointer and integral or incompatible pointer types; thusnumber = spell_out_numbers ? forty-two : 42;

10 CHAPTER 1. ?:

will result in a compile-time error in most compilers.

1.4 ?: in style guidelines

Some corporate programming guidelines list the use of the conditional operator as bad practice because it can harmreadability and long-term maintainability. Conditional operators are widely used and can be useful in certain cir-cumstances to avoid the use of an if statement, either because the extra verbiage would be too lengthy or because thesyntactic context does not permit a statement. For example:#dene MAX(a, b) (((a)>(b)) ? (a) : (b))orfor (i = 0; i < MAX_PATTERNS; i++) c_patterns[i].ShowWindow(m_data.fOn[i] ? SW_SHOW : SW_HIDE);

(The latter example uses the Microsoft Foundation Classes Framework for Win32.)

1.4.1 Initialization

An important use of the conditional operator is in allowing a single initialization statement, rather than multipleinitialization statements. In many cases this also allows single assignment and for an identier to be a constant.The simplest benet is avoiding duplicating the variable name, as in Python:x = 'foo' if b else 'bar'

instead of:if b: x = 'foo' else: x = 'bar'

More importantly, in languages with block scope, such as C++, the blocks of an if/else statement creates new scopes,and thus variables must be declared before the if/else statement, as:std::string s; if (b) s = 'foo'; else s = 'bar';

Use of the conditional operator simplies this:std::string s = b ? 'foo' : 'bar';

Further, since initialization is now part of the declaration, rather than a separate statement, the identier can be aconstant (formally, of const type):const std::string s = b ? 'foo' : 'bar';

1.4.2 Case selectors

When properly formatted, the conditional operator can be used to write simple and coherent case selectors. Forexample:vehicle = arg == 'B' ? bus : arg == 'A' ? airplane : arg == 'T' ? train : arg == 'C' ? car : arg == 'H' ? horse : feet;

Appropriate use of the conditional operator in a variable assignment context reduces the probability of a bug from afaulty assignment as the assigned variable is stated just once as opposed to multiple times.

1.5. PROGRAMMING LANGUAGES WITHOUT THE CONDITIONAL OPERATOR 11

1.5 Programming languages without the conditional operatorThe following are examples of notable general-purpose programming languages that don't provide a conditional op-erator:

Go programming language[13]

MATLAB

Pascal Although Object Pascal / Delphi do have a function IfThen to do the same (with caveats)

Rust The if..else construct is an expression and can be used to get the same functionality.[14]

XProfan

1.6 See also IIf, inline if function

Null coalescing operator, ?? operator

Elvis operator, ?: as a shorthand binary operator

Conditioned disjunction, equivalent ternary logical connective.

1.7 References[1] Strachey, Christopher (2000). "Fundamental Concepts in Programming Languages". Higher-Order and Symbolic Compu-

tation 13: 1149. doi:10.1023/A:1010000313106.

[2] BCPL Ternary operator (page 15)" (PDF). BCPL Reference Manual.

[3] Learning GNU C: The Conditional Operator

[4] ISO.IEC 9899:1999 (E) 6.5.15.4

[5] Java 7 Specication: 15.25 Conditional Operator ? :

[6] ECMA-262 Edition 5.1. Ecma Language Specication. Ecma International. Retrieved 7 September 2013.

[7] Perl6 Operators. Larry Wall. Retrieved 2010-05-18.

[8] Eevee (2012-04-09). PHP: a fractal of bad design. Retrieved 2013-04-26.

[9] Comparison Operators, Example #3: Non-obvious Ternary Behaviour. PHP website. Retrieved 2013-04-26.

[10] PHP Bug #61915: incorrect associativity of ternary operator. PHP website. 2012-05-02. Retrieved 2013-04-26. Wecan't x this without breaking code

[11] PHP 5.3.0 Release Announcement. PHP website. Retrieved 2013-04-26. Syntax additions: NOWDOC, ternary shortcut "?:" and jump label (limited goto), __callStatic()

[12] Programming Ruby: Conditional Execution

[13] Does Go have the ?: operator?". The Go Programming Language FAQ. Retrieved 2012-08-05.

[14] If expressions. The Rust Reference. Retrieved 2015-07-21.

12 CHAPTER 1. ?:

1.8 External links Description of Conditional Operator in C# Description of If operator in Visual Basic Description of Conditional Expression in Python (PEP 308) Alternative workaround for conditional operator expression in Python Description in the Java Language Specication Description in the PHP Language Documentation Visual Basic 9.0 Language Specication

Chapter 2

Anankastic conditional

An anankastic[1] conditional is a grammatical construction of the form

If you want X, you have to do Y.

where Y is required in order to get X. For example:

If you wanna be my lover, you gotta get with my friends.[2]

2.1 Notes[1] From Greek compulsory from necessity.

[2] Wannabe (song)

2.2 External links Opiniatrety If You Want To Get To Sugar Hill in Harlem

13

Chapter 3

Antecedent (logic)

An antecedent is the rst half of a hypothetical proposition, whenever the if-clause precedes the then-clause. It isalso known for a persons principles to a possible or hypothetical issue.Examples:

If P, then Q.

This is a nonlogical formulation of a hypothetical proposition. In this case, the antecedent is P, and the consequentis Q. In an implication, if implies then is called the antecedent and is called the consequent.[1]

If X is a man, then X is mortal.

X is a man is the antecedent for this proposition.

If men have walked on the moon, then I am the king of France.

Here, men have walked on the moon is the antecedent.

3.1 See also Arming the consequent (fallacy) Denying the antecedent (fallacy) Necessity and suciency

3.2 References[1] Sets, Functions and Logic - An Introduction to Abstract Mathematics, Keith Devlin, Chapman & Hall/CRC Mathematics,

3rd ed., 2004

14

Chapter 4

Arithmetic IF

The arithmetic IF statement has been for several decades a three-way arithmetic conditional statement, starting fromthe very early version (1957) of Fortran, and including FORTRAN IV, FORTRAN 66, FORTRAN 77, Fortran 90,Fortran 95, Fortran 2003, and Fortran 2008. Unlike the logical IF statements seen in other languages, the Fortranstatement denes three dierent branches depending on whether the result of an expression was negative, zero, orpositive, in said order, written as:IF (expression) negative,zero,positive

While it was originally the only kind of IF statement provided in Fortran, the feature was used less and less frequentlyafter the more powerful logical IF statements were introduced, and was nally labeled obsolescent in Fortran 90. Nofeatures have been deleted from Fortran since Fortran 90.The arithmetic IF is also in FOCAL.

4.1 See also Sign function Three-way comparison Conditional (programming)

4.2 References arithmetic IF @ everything2.com Modular Programming with Fortran 90 - Obsolescent Features

15

Chapter 5

Assertion (software development)

In computer programming, an assertion is a statement that a predicate (Boolean-valued function, a truefalse expression)is expected to always be true at that point in the code. If an assertion evaluates to false at run time, an assertion failureresults, which typically causes the program to crash, or to throw an assertion exception.

5.1 Details

The following code contains two assertions, x > 0 and x > 1, and they are indeed true at the indicated points duringexecution:x = 1; assert (x > 0); x++; assert (x > 1);

Programmers can use assertions to help specify programs and to reason about program correctness. For example, apreconditionan assertion placed at the beginning of a section of codedetermines the set of states under whichthe programmer expects the code to execute. A postconditionplaced at the enddescribes the expected state atthe end of execution. For example: x > 0 { x++ } x > 1The example above uses the notation for including assertions used by C.A.R. Hoare in his 1969 paper.[1] That notationcannot be used in existing mainstream programming languages. However, programmers can include uncheckedassertions using the comment feature of their programming language. For example, in C:x = 5; x = x + 1; // {x > 1}

The braces included in the comment help distinguish this use of a comment from other uses.Libraries may provide assertion features as well. For example, in C using glibc with C99 support:#include x = 5; x = x + 1; assert(x > 1);

Several modern programming languages include checked assertions - statements that are checked at runtime or some-times statically. If an assertion evaluates to false at run-time, an assertion failure results, which typically causes execu-tion to abort. This draws attention to the location at which the logical inconsistency is detected and can be preferableto the behaviour that would otherwise result.The use of assertions helps the programmer design, develop, and reason about a program.

5.2 Usage

In languages such as Eiel, assertions form part of the design process; other languages, such as C and Java, use themonly to check assumptions at runtime. In both cases, they can be checked for validity at runtime but can usually alsobe suppressed.

16

5.2. USAGE 17

5.2.1 Assertions in design by contractAssertions can function as a form of documentation: they can describe the state the code expects to nd before it runs(its preconditions), and the state the code expects to result in when it is nished running (postconditions); they canalso specify invariants of a class. Eiel integrates such assertions into the language and automatically extracts themto document the class. This forms an important part of the method of design by contract.This approach is also useful in languages that do not explicitly support it: the advantage of using assertion statementsrather than assertions in comments is that the program can check the assertions every time it runs; if the assertion nolonger holds, an error can be reported. This prevents the code from getting out of sync with the assertions.

5.2.2 Assertions for run-time checkingAn assertion may be used to verify that an assumption made by the programmer during the implementation of theprogram remains valid when the program is executed. For example, consider the following Java code:int total = countNumberOfUsers(); if (total % 2 == 0) { // total is even } else { // total is odd and non-negativeassert(total % 2 == 1); }

In Java, % is the remainder operator (modulo), and in Java, if its rst operand is negative, the result can also benegative (unlike the modulo used in mathematics). Here, the programmer has assumed that total is non-negative,so that the remainder of a division with 2 will always be 0 or 1. The assertion makes this assumption explicit: ifcountNumberOfUsers does return a negative value, the program may have a bug.A major advantage of this technique is that when an error does occur it is detected immediately and directly, ratherthan later through its often obscure side-eects. Since an assertion failure usually reports the code location, one canoften pin-point the error without further debugging.Assertions are also sometimes placed at points the execution is not supposed to reach. For example, assertions couldbe placed at the default clause of the switch statement in languages such as C, C++, and Java. Any case which theprogrammer does not handle intentionally will raise an error and the program will abort rather than silently continuingin an erroneous state. In D such an assertion is added automatically when a switch statement doesn't contain a defaultclause.In Java, assertions have been a part of the language since version 1.4. Assertion failures result in raising an Asser-tionError when the program is run with the appropriate ags, without which the assert statements are ignored. In C,they are added on by the standard header assert.h dening assert (assertion) as a macro that signals an error in thecase of failure, usually terminating the program. In standard C++ the header cassert is required instead. However,some C++ libraries still have the assert.h available.The danger of assertions is that they may cause side eects either by changing memory data or by changing threadtiming. Assertions should be implemented carefully so they cause no side eects on program code.Assertion constructs in a language allow for easy test-driven development (TDD) without the use of a third-partylibrary.

5.2.3 Assertions during the development cycleDuring the development cycle, the programmer will typically run the program with assertions enabled. When anassertion failure occurs, the programmer is immediately notied of the problem. Many assertion implementationswill also halt the programs execution: this is useful, since if the program continued to run after an assertion violationoccurred, it might corrupt its state and make the cause of the problem more dicult to locate. Using the informationprovided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full programstate if the environment supports core dumps or if the program is running in a debugger), the programmer can usuallyx the problem. Thus assertions provide a very powerful tool in debugging.

5.2.4 Assertions in production environmentWhen a program is deployed to production, assertions are typically turned o, to avoid any overhead or side eectsthey may have. In some cases assertions are completely absent from deployed code, such as in C/C++ assertions via

18 CHAPTER 5. ASSERTION (SOFTWARE DEVELOPMENT)

macros. In other cases, such as Java, assertions are present in the deployed code, and can be turned on in the eld fordebugging.[2]

5.2.5 Static assertions

Assertions that are checked at compile time are called static assertions.Static assertions are particularly useful in compile time template metaprogramming, but can also be used in low-level languages like C by introducing illegal code if (and only if) the assertion fails. C11 and C++11 support staticassertions directly through static_assert. In earlier C versions, a static assertion can be implemented, for example,like this:#dene SASSERT(pred) switch(0){case 0:case pred:;} SASSERT( BOOLEAN CONDITION );

If the (BOOLEAN CONDITION) part evaluates to false then the above code will not compile because the compilerwill not allow two case labels with the same constant. The boolean expression must be a compile-time constant value,for example (sizeof(int)==4) would be a valid expression in that context. This construct does not work at le scope(i.e. not inside a function), and so it must be wrapped inside a function.Another popular [3] way of implementing assertions in C is:static char const static_assertion[ (BOOLEAN CONDITION) ? 1 : 1 ] = {'!'};

If the (BOOLEAN CONDITION) part evaluates to false then the above code will not compile because arrays maynot have a negative length. If in fact the compiler allows a negative length then the initialization byte (the '!' part)should cause even such over-lenient compilers to complain. The boolean expression must be a compile-time constantvalue, for example (sizeof(int)==4) would be a valid expression in that context.Both of these methods require a method of constructing unique names. Modern compilers support a __COUNTER__preprocessor dene that facilitates the construction of unique names, by returning monotonically increasing numbersfor each compilation unit.[4]

D provides static assertions through the use of static assert,.[5]

5.3 Disabling assertionsMost languages allow assertions to be enabled or disabled globally, and sometimes independently. Assertions areoften enabled during development and disabled during nal testing and on release to the customer. Not checkingassertions avoids the cost of evaluating the assertions while (assuming the assertions are free of side eects) stillproducing the same result under normal conditions. Under abnormal conditions, disabling assertion checking canmean that a program that would have aborted will continue to run. This is sometimes preferable.Some languages, including C and C++, completely remove assertions at compile time using the preprocessor. Javarequires an option to be passed to the run-time engine in order to enable assertions. Absent the option, assertions arebypassed, but they always remain in the code unless optimised away by a JIT compiler at run-time or excluded by anif(false) condition at compile time, thus they need not have a run-time space or time cost in Java either.Programmers can build checks into their code that are always active by bypassing or manipulating the languagesnormal assertion-checking mechanisms.

5.4 Comparison with error handlingAssertions are distinct from routine error-handling. Assertions document logically impossible situations and discoverprogramming errors: if the impossible occurs, then something fundamental is clearly wrong with the program. Thisis distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occurin practice. Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow forrecovery from errors; an assertion failure will normally halt the programs execution abruptly. Assertions also do notdisplay a user-friendly error message.

5.5. HISTORY 19

Consider the following example of using an assertion to handle an error:int *ptr = malloc(sizeof(int) * 10); assert(ptr); // use ptr ...

Here, the programmer is aware that malloc will return a NULL pointer if memory is not allocated. This is possible:the operating system does not guarantee that every call to malloc will succeed. If an out of memory error occurs theprogram will immediately abort. Without the assertion, the program would continue running until ptr was derefer-enced, and possibly longer, depending on the specic hardware being used. So long as assertions are not disabled, animmediate exit is assured. But if a graceful failure is desired, the program has to handle the failure. For example, aserver may have multiple clients, or may hold resources that will not be released cleanly, or it may have uncommittedchanges to write to a datastore. In such cases it is better to fail a single transaction than to abort abruptly.Another error is to rely on side eects of expressions used as arguments of an assertion. One should always keep inmind that assertions might not be executed at all, since their sole purpose is to verify that a condition which shouldalways be true does in fact hold true. Consequently, if the program is considered to be error-free and released,assertions may be disabled and will no longer be evaluated.Consider another version of the previous example:int *ptr; // Statement below fails if malloc() returns NULL, // but is not executed at all when compiling with -NDEBUG! assert(ptr = malloc(sizeof(int) * 10)); // use ptr: ptr isn't initialised when compiling with -NDEBUG! ...

This might look like a smart way to assign the return value of malloc to ptr and check if it is NULL in one step, butthe malloc call and the assignment to ptr is a side eect of evaluating the expression that forms the assert condition.When the NDEBUG parameter is passed to the compiler, as when the program is considered to be error-free andreleased, the assert() statement is removed, so malloc() isn't called, rendering ptr uninitialised. This could potentiallyresult in a segmentation fault or similar null pointer error much further down the line in program execution, causingbugs that may be sporadic and/or dicult to track down. Programmers sometimes use a similar VERIFY(X) deneto alleviate this problem.

5.5 HistoryIn 1947 reports by von Neumann and Goldstine [6] on their design for the IAS machine, they described algorithmsusing an early version of ow charts, in which they included assertions - It may be true, that whenever C actuallyreaches a certain point in the ow diagram, one or more bound variables will necessarily possess certain speciedvalues, or possess certain properties, or satisfy certain properties with each other. Furthermore, we may, at such apoint, indicate the validity of these limitations. For this reason we will denote each area in which the validity of suchlimitations is being asserted, by a special box, which we call an assertion box.The assertional method for proving correctness of programs was advocated by Alan Turing. In a talk Checking aLarge Routine at Cambridge, June 24, 1949 Turing suggested: How can one check a large routine in the senseof making sure that its right? In order that the man who checks may not have too dicult a task, the programmershould make a number of denite assertions which can be checked individually, and from which the correctness ofthe whole program easily follows.[7]

5.6 See also Assertion denition language Design by contract Exception handling Hoare logic Static code analysis Java Modeling Language Invariant (computer science)

20 CHAPTER 5. ASSERTION (SOFTWARE DEVELOPMENT)

5.7 References[1] C.A.R. Hoare, An axiomatic basis for computer programming, Communications of the ACM, 1969.

[2] Programming With Assertions, Enabling and Disabling Assertions

[3] Jon Jagger, Compile Time Assertions in C, 1999.

[4] GNU, GCC 4.3 Release Series Changes, New Features, and Fixes

[5] Static assertions in Dhttp://dlang.org/version.html#StaticAssert''

[6] Goldstine and von Neumann Planning and Coding of problems for an Electronic Computing Instrument. Part II, VolumeI, 1 April 1947, p.12

[7] Alan Turing, Checking a Large Routine, 1949; quoted in C.A.R Hoare, The Emperors Old Clothes, 1980 Turing Awardlecture

5.8 External links Programming With Assertions in Java by Qusay H. Mahmoud, (Oracle Corp.), 2005 A historical perspective on runtime assertion checking in software development by Lori A. Clarke, David S.Rosenblum in: ACM SIGSOFT Software Engineering Notes 31(3):25-37, 2006

The benets of programming with assertions by Philip Guo (Stanford University), 2008 Assertions: a personal perspective by C.A.R. Hoare in: Annals of the History of Computing, IEEE, Volume:25, Issue: 2 (2003), Page(s): 14 - 25

My Compiler Does Not Understand Me by Poul-Henning Kamp in: ACM Queue 10(5), May 2012

Chapter 6

Branch predication

Not to be confused with branch prediction.

Branch predication is a strategy in computer architecture design for mitigating the costs usually associated withconditional branches, particularly branches to short sections of code. It does this by allowing each instruction toconditionally either perform an operation or do nothing.[1]

6.1 OverviewMost computer programs contain code which will be executed only under specic conditions depending on factorswhich cannot be determined before-hand, for example user input. As the majority of processors simply executethe next instruction in a sequence, the traditional solution is to insert branch instructions that allow a program toconditionally branch to a dierent section of code, thus changing the next step in the sequence. This was sucientuntil designers began improving performance by implementing instruction pipelining, a method which is sloweddown by branches. For a more thorough description of the problems which arose, and a popular solution, see branchpredictor.Luckily, one of the more common patterns of code that normally relies on branching has a more elegant solution.Consider the following pseudocode:[1]

if condition do this else do thatOn a system that uses conditional branching, this might translate to machine instructions looking similar to:[1]

branch if condition to label 1 do that branch to label 2 label 1: do this label 2: ...With branch predication, all possible branch paths are coded inline, but some instructions execute while others donot. The basic idea is that each instruction is associated with a predicate (the word here used similarly to its usagein predicate logic) and that the instruction will only be executed if the predicate is true. The machine code for theabove example using branch predication might look something like this:[1]

(condition) do this (not condition) do thatNote that beside eliminating branches, less code is needed in total, provided the architecture provides predicatedinstructions. While this does not guarantee faster execution in general, it will if the do this and do that blocks of codeare short enough.Typically, in order to claim a system has branch predication, most or all of the instructions must have this ability toexecute conditionally based on a predicate.

6.2 AdvantagesThe main purpose of predication is to avoid jumps over very small sections of program code, increasing the eec-tiveness of pipelined execution and avoiding problems with the cache. It also has a number of more subtle benets:

21

22 CHAPTER 6. BRANCH PREDICATION

Functions that are traditionally computed using simple arithmetic and bitwise operations may be quicker tocompute using predicated instructions.

Predicated instructions with dierent predicates can be mixed with each other and with unconditional code,allowing better instruction scheduling and so even better performance.

Elimination of unnecessary branch instructions can make the execution of necessary branches, such as thosethat make up loops, faster by lessening the load on branch prediction mechanisms.

Elimination of the cost of a branch misprediction which can be high on deeply pipelined architectures.

6.3 DisadvantagesPredications primary drawback is in increased encoding space. In typical implementations, every instruction reservesa biteld for the predicate specifying under what conditions that instruction should have an eect. When availablememory is limited, as on embedded devices, this space cost can be prohibitive. However, some architectures such asThumb-2 are able to avoid this issue (see below). Other detriments are the following:[2]

Predication complicates the hardware by adding levels of logic to critical paths and potentially degrades clockspeed.

A predicated block includes cycles for all operations, so shorter paths may take longer and be penalized.

Predication is most eective when paths are balanced or when the longest path is the most frequently executed,[2] butdetermining such a path is very dicult at compile time, even in the presence of proling information.

6.4 HistoryPredicated instructions were popular in European computer designs of the 1950s, including theMailfterl (1955), theZuse Z22 (1955), the ZEBRA (1958), and the Electrologica X1 (1958). The IBM ACS-1 design of 1967 allocateda skip bit in its instruction formats, and the CDC Flexible Processor in 1976 allocated three conditional executionbits in its microinstruction formats.In Intel's IA-64 architecture, almost every instruction in the IA-64 instruction set is predicated. The predicatesthemselves are stored in special purpose registers; one of the predicate registers is always true so that unpredicatedinstructions are simply instructions predicated with the value true. The use of predication is essential in the IA-64implementation of software pipelining because it avoids the need for writing separated code for prologs and epilogs.In x86-64 architectures from both Intel and AMD, branch predication may be performed through the use of condi-tional move operations (cmove): a source operand is conditionally moved to the destination operand depending onthe value of a ag register.In the 32-bit ARM architecture, almost all instructions can be conditionally executed. Thirteen dierent predicatesare available, each depending on the four ags Carry, Overow, Zero, and Negative in some way. The ARMs 16-bit Thumb instruction set has no branch predication, in order to save encoding space, but its successor Thumb-2overcomes this problem using a special instruction which has no eect other than to supply predicates for the nextfour instructions. The 64-bit version of the ARM architecture does not support branch predication.

6.5 See also Control ow Delay slot Bubble (computing) Compiler optimization

6.6. REFERENCES 23

Branch predictor Speculative execution Software pipelining Instruction level parallelism Very long instruction word

6.6 References[1] Rick Vinyard (2000-04-26). Predication. cs.nmsu.edu. Retrieved 2014-04-22.

[2] Joseph A. Fisher, Paolo Faraboschi, Cli Young (2004) Embedded Computing - A VLIW Approach to Architecture, Com-pilers, and Tools. Page 172.

6.7 Further reading Alan Clements (2013). Computer Organization & Architecture: Themes and Variations. Cengage Learning.pp. 532539. ISBN 1-285-41542-6.

Chapter 7

Branch table

In computer programming, a branch table or jump table is a method of transferring program control (branching) toanother part of a program (or a dierent program that may have been dynamically loaded) using a table of branch orjump instructions. It is a form of multiway branch. The branch table construction is commonly used when program-ming in assembly language but may also be generated by a compiler, especially when implementing an optimizedswitch statement where known, small ranges are involved with few gaps.

7.1 Typical implementationA branch table consists of a serial list of unconditional branch instructions that is branched into using an oset createdby multiplying a sequential index by the instruction length (the number of bytes in memory occupied by each branchinstruction). It relies on the fact that machine code instructions for branching have a xed length and can be executedextremely eciently by most hardware, and is most useful when dealing with raw data values that may be easilyconverted to sequential index values. Given such data, a branch table can be extremely ecient. It usually consists ofthe following 3 steps:

1. optionally validating the input data to ensure it is acceptable (this may occur without cost as part of the nextstep, if the input is a single byte and a 256 byte translate table is used to directly obtain the oset below). Also,if there is no doubt about the values of the input, this step can be omitted.

2. transform the data into an oset into the branch table. This usually involves multiplying or shifting (eectivelymultiplying by a power of 2) it to take into account the instruction length. If a static translate table is used, thismultiplying can be performed manually or by the compiler, without any run time cost.

3. branching to an address made up of the base address of the branch table plus the just generated oset. Thissometimes involves an addition of the oset onto the program counter register (unless, in some instruction sets,the branch instruction allows an extra index register). This nal address usually points to one of a sequence ofunconditional branch instructions, or the instruction immediately beyond them (saving one entry in the table).

The following pseudocode illustrates the concept... validate x /* transform x to 0 (invalid) or 1,2,3, according to value..) */ y = x*4; /* multiply by branch instructionlength (e.g. 4 ) */ goto next(y); /* branch into 'table' of branch instructions */ /* start of branch table */ next: gotocodebad; /* x= 0 (invalid) */ goto codeone; /* x= 1 */ goto codetwo; /* x= 2 */ ... rest of branch table codebad: /*deal with invalid input */

7.2 Alternative implementation using addressesAnother method of implementing a branch table is with an array of pointers from which the required functionsaddress is retrieved. This method is also more recently known under such dierent names as "dispatch table" or"virtual method table" but essentially performing exactly the same purpose. This pointer function method can resultin saving one machine instruction, and avoids the indirect jump (to one of the branch instructions).

24

7.3. HISTORY 25

The resulting list of pointers to functions is almost identical to direct threaded code, and is conceptually similar to acontrol table.The actual method used to implement a branch table is usually based on:

the architecture of the processor on which the code is to be executed, whether it is a compiled or interpreted language and whether late binding is involved or not.

7.3 HistoryUse of branch tables and other raw data encoding was common in the early days of computing when memory wasexpensive, CPUs were slower and compact data representation and ecient choice of alternatives were important.Nowadays, they are commonly still used in:

embedded programming operating system development. In many operating systems, both system calls and library functions may bereferenced by an integer index into a branch table.

some computer architectures such as IBM/360 use branch tables for dispatching interrupts

7.4 AdvantagesAdvantages of branch tables include:

compact code structure (despite repeated branch opcodes) reduced source statements (versus repetitive If statements) reduced requirement to test return codes individually (if used at call site to determine subsequent program ow) Algorithmic and code eciency (data need only be encoded once and branch table code is usually compact),and the potential to attain high data compression ratios. For example, when compressing country names tocountry codes, a string such as Central African Republic can be compressed to a single index, resulting inlarge savings particularly when the string appears many times. In addition, this same index can be used toaccess related data in separate tables, reducing storage requirements further.

For library functions, where they may be referenced by an integer:

improve compatibility with subsequent software versions. If the code of a function and the address of its entrypoint is changed, only the branch instruction in the branch table needs to be adjusted; application softwarecompiled against the library, or for the operating system, does not need modication.

In addition, calling functions by number (the index into the table) can sometimes be useful in some cases in normalapplication programming.

7.5 Disadvantages Extra level of i