ISBN 0-321-33025-0Chapter 7Chapter 7Chapter 7Chapter 7Expressions and Assignment StatementsCopyright © 2006 Addison-Wesley. All rights reserved. 1-2Chapter 7 Topics• Introduction• Arithmetic Expressions• Overloaded Operators• Type Conversions• Relational and Boolean Expressions• Short-Circuit Evaluation• Assignment Statements• Mixed-Mode AssignmentCopyright © 2006 Addison-Wesley. All rights reserved. 1-3Introduction• Expressions are the fundamental means of specifying computations in a programming language• To understand expression evaluation, need to be familiar with the orders of operator and operand evaluation• Essence of imperative languages is dominant role of assignment statementsCopyright © 2006 Addison-Wesley. All rights reserved. 1-4Arithmetic Expressions• Arithmetic evaluation was one of the motivations for the development of the first programming languages• Arithmetic expressions consist of operators, operands, parentheses, and function callsCopyright © 2006 Addison-Wesley. All rights reserved. 1-5Arithmetic Expressions: Design Issues• Design issues for arithmetic expressions– operator precedence rules– operator associativity rules– order of operand evaluation– operand evaluation side effects– operator overloading– mode mixing expressionsCopyright © 2006 Addison-Wesley. All rights reserved. 1-6Arithmetic Expressions: Operators• A unary operator has one operand• A binary operator has two operands• A ternary operator has three operandsCopyright © 2006 Addison-Wesley. All rights reserved. 1-7Arithmetic Expressions: Operator Precedence Rules• The operator precedence rulesfor expression evaluation define the order in which “adjacent” operators of different precedence levels are evaluated • Typical precedence levels– parentheses– unary operators– ** (if the language supports it)– *, /– +, -Copyright © 2006 Addison-Wesley. All rights reserved. 1-8Arithmetic Expressions: Operator Associativity Rule• The operator associativity rulesfor expression evaluation define the order in which adjacent operators with the same precedence level are evaluated• Typical associativity rules– Left to right, except **, which is right to left– Sometimes unary operators associate right to left (e.g., in FORTRAN)• APL is different; all operators have equal precedence and all operators associate right to left• Precedence and associativity rules can be overridenwith parenthesesCopyright © 2006 Addison-Wesley. All rights reserved. 1-9Arithmetic Expressions: Conditional Expressions• Conditional Expressions– C-based languages (e.g., C, C++)– An example:average = (count == 0)? 0 : sum / count– Evaluates as if written likeif (count == 0) average = 0else average = sum /countCopyright © 2006 Addison-Wesley. All rights reserved. 1-10Arithmetic Expressions: Operand Evaluation Order•Operand evaluation order1. Variables: fetch the value from memory2. Constants: sometimes a fetch from memory; sometimes the constant is in the machine language instruction3. Parenthesized expressions: evaluate all operands and operators firstCopyright © 2006 Addison-Wesley. All rights reserved. 1-11Arithmetic Expressions: Potentials for Side Effects•Functional side effects:when a function changes a two-way parameter or a non-local variable• Problem with functional side effects: – When a function referenced in an expression alters another operand of the expression; e.g., for a parameter change: a = 10;/* assume that fun changes its parameter */b = a + fun(a);Copyright © 2006 Addison-Wesley. All rights reserved. 1-12Functional Side Effects• Two possible solutions to the problem1. Write the language definition to disallow functional side effects• No two-way parameters in functions• No non-local references in functions• Advantage:Advantage:Advantage:Advantage: it works!• Disadvantage:Disadvantage:Disadvantage:Disadvantage: inflexibility of two-way parameters and non-local references2. Write the language definition to demand that operand evaluation order be fixed• DisadvantageDisadvantageDisadvantageDisadvantage: limits some compiler optimizationsCopyright © 2006 Addison-Wesley. All rights reserved. 1-13Overloaded Operators• Use of an operator for more than one purpose is called operator overloading• Some are common (e.g., + for int and float)• Some are potential trouble (e.g., * in C and C++)– Loss of compiler error detection (omission of an operand should be a detectable error)– Some loss of readability– Can be avoided by introduction of new symbols (e.g., Pascal’s div for integer division)Copyright © 2006 Addison-Wesley. All rights reserved. 1-14Overloaded Operators (continued)• C++ and Ada allow user-defined overloaded operators• Potential problems: – Users can define nonsense operations– Readability may suffer, even when the operators make senseCopyright © 2006 Addison-Wesley. All rights reserved. 1-15Type Conversions• A narrowing conversionis one that converts an object to a type that cannot include all of the values of the original type e.g., float to int• A widening conversionis one in which an object is converted to a type that can include at least approximations to all of the values of the original type e.g., int to floatCopyright © 2006 Addison-Wesley. All rights reserved. 1-16Type Conversions: Mixed Mode• A mixed-mode expressionis one that has operands of different types• A coercionis an implicit type conversion• Disadvantage of coercions:– They decrease in the type error detection ability of the compiler • In most languages, all numeric types are coerced in expressions, using widening conversions• In Ada, there are virtually no coercions in expressionsCopyright © 2006 Addison-Wesley. All rights reserved. 1-17Explicit Type Conversions• Explicit Type Conversions• Called castingin C-based language• Examples–C: (int) angle–Ada: Float (sum)Note that AdaNote that AdaNote that AdaNote that Ada’’’’s syntax is similar to function s syntax is similar to function s syntax is similar to function s syntax is similar to function callscallscallscallsCopyright © 2006 Addison-Wesley. All rights reserved. 1-18Type Conversions: Errors in Expressions• Causes– Inherent limitations of arithmetic e.g., division by zero– Limitations of computer arithmetic e.g. overflow• Often ignored by the run-time systemCopyright © 2006 Addison-Wesley. All