表达式分析和总结.docxVIP

表达式 作用在一个操作数上的操作符被称为一元操作符(unary operator)，比如取地址操作符()和解引用操作符(*)。解引用操作符返回的是指向的存储区存储的值。 C++严格定义了子表达式的计算顺序：如果左边的子表达式的值为false，则不计算右边的子表达式。 算术操作符 两个整数相除的结果是整数。如果商含有小数部分，将被截掉，例如： int ival1 = 21 / 6; int ival2 = 21 / 7; 结果是，ival1 和 ival2 都被 3 初始化。 %操作符计算两个数相除的余数，第一个数被第二个数除。该操作符只能被应用在整值类型(char, short, int 和 long)的操作数上。当两个操作数都是正数时，结果为正。但是，如果有一个（或两个）操作数为负，余数的符号则取决于机器。因此，移植性无法保证。%操作符被 称为取模(modulus)或求余(remainder)操作符。 3.14 % 3; // 编译时刻错误: 浮点操作数 21 % 6; // ok: 结果是 3 21 % 7; // ok: 结果是 0 21 % -5; // 机器相关: 结果为 -1 或 1 int ival = 1024; double dval = 3.14159; ival % 12; // ok: 返回值在0 和11 之间 ival % dval; // 编译时刻错误: 浮点操作数 在某些实例中，算术表达式的计算会导致不正确或未定义的值，这些情况被称为算术异常 (arithmetic exception)（但是不会导致抛出实际的异常）。算术异常要归咎于算术的自然本质 （比如除以 0）或归咎于计算机的自然本质-比如溢出(overflow)（指结果值超出了被赋值对象的类型长度）。例如 8 位的 char。根据它有符号还是无符号，它可以包含最大数127 或 255。下面的乘法向一个 char 赋值 256,因而导致了溢出： #include iostream int main() { char byte_value = 32; int ival = 8; // overflow of byte_values available memory byte_value = ival * byte_value; cout byte_value: static_castint(byte_value) endl; } 表示 256 需要 9 位，因而向 byte_value 赋值 256 导致了与其相关联的内存的溢出。byte_value 包含的实际值是未定义的，所以在执行时就可能会引起问题。例如，在 SGI 工作站上， byte_value 被设置为 0。当用表达式： cout byte_value: byte_value endl; 试图输出它时，程序输出结果如下： byte_value: 经过几分钟的迷惑之后，我们意识到，在 ASCII 码集中，0 代表空(null)字符，所以什么也不输出。如下特殊表达式： static_castint ( byte_value ) 称为显式类型转换(explicit type conversion)或强制类型转换(cast)。强制转换使编译器把一个对象（或表达式）从它当前的类型转换成程序员指定的类型。 在这种情况下，我们把byte_value 转换成一个 int 型的对象。现在程序输出： byte_value: 0 在本例中，我们改变的不是 byte_value 相关的值，而是它被输出操作符解释的方式。当它被当作 char 型时，它的值被映射到相关联的 ASCII 表示上（例如，12 表示换行，97 表示小写a, 0 代表空字符等），输出的是它所代表的字符，而不是它的值。当它被看作int 型时，它的值被直接输出。 我们的叙述需要中断一下，转而讨论类型转换以及 byte_value 的输出失败，这有点类似于我们常遇到的情况-即， 当程序不能如我们期望的那样运行时，就需要把程序设计任务先放下， 去查看一下出了什么问题。那些看起来比较晦涩、并不有趣的语言要素，比如数据类型的长 度等，在实践中有时候会影响我们所写的程序。例如，发生在byte_value 上的溢出错误，就不会被语言捕捉到，因为它涉及到每个计算的运行时刻检查，从性能的角度来看，这是不切 合实际的。但是我们必须知道，它是有发生的可能性的。 标准 C++头文件 limits 提供了与内置类型表示有关的信息，例如一个类型能表示的最大值与最小值。另外，C++编译系统也提供了标准 C 头文件 climits 和 cfloat，它们定义了提供类似信息的预处理器宏。怎样使用这些头文件来防止溢出(overflow)和下溢(un