混合运算中不同数据类型之间的隐式转换原则(C语言)

时间:2024-02-24 13:42:41

C语言的数据类型

c语言中,有关数据类型的分类,网上有很多种版本,未找到比较统一的标准,下图为我比较认可的划分:

常量的默认类型

在C语言中,数值常量分为两种:整数和小数。整数常量默认为有符号的 int 类型,而小数常量默认为 double 类型。字符常量被认为是一种特殊的整型常量,默认类型为有符号的 char ,而字符串常量一般被认为 const char 类型。需要注意的是,不同的编译器可能略有不同,但一般遵守该规则。

隐式转换

C语言在以下四种情况中会进行隐式转换:
(1)算术运算式中,类型能够换为类型。

    所谓高低,是指表示的范围大小。通常和内存默认分配的存储空间大小及有无符号位有关。

(2)赋值表达式中,右边表达式的值自动隐式换为左边变量的类型,并赋值给它。
(3)函数调用中参数传递时,系统隐式地将实参转换为形参的类型后,赋给形参。
(4)函数有返回值时,系统将隐式地将返回表达式类型换为返回值类型,赋值给调用函数。

算数运算中的转换规则

算数运算中,有如下类型转换规则:

(1)字符必须先转换为整数(C语言规定字符类型数据和整型数据之间可以通用) 。
(2) short 型换为 int 型(同属于整型) 。
(3) float 型数据在运算时一律换为双精度 double 型,以提高运算精度(同属于实型,即浮点型) 。

总的来说,当不同类型的数据进行操作时,应当首先将其转换成相同的数据类型,然后进行操作,转换规则是由低级向高级转换(如上图所示)。

算术运算示例

执行: x = 100 + \'a\' + 1.5 * u + f / \'b\' - s * 3.1415926 

其中,u为 unsigned 型,f为 float 型,s为 short 型,x为 float 型。式中右面表达式按如下步骤处理:

  1. 首先将\'a\'、\'b\'和s换成 int ,将1.5和f转换为 double 型。
  2. 计算100+\'a\',因\'a\'已转换为 int 型,于是此运算结果为197。
  3. 计算1.5*u,由于1.5已转换为 double ,u是 unsigned 型,于是首先u转换为 double ,然后进行运算,运算结果为 double 。
  4. 计算197+1.5 * u,先将197转换为 double (如197.00…00),其结果为 double 。
  5. 计算f/ \'b\',f已转换为 double ,\'b\'已转换为 int ,于是先将\'b\'再转换为 double ,其结果为 double 。
  6. 计算(197+1.5 * u)+f / \'b\',者均为 double ,于是结果也为 double 。
  7. 计算s * 3.1415926,先将s由int转换为 double ,然后进行运算,其结果为 double 。
  8. 之后与前面得的结果相减,结果为 double 。
  9. 最后将表达式的结果转换为 float 并赋给x。

有符号数与无符号数之间运算问题

当表达式中存在有符号类型和无符号类型时,所有的操作数都自动转换为无符号类型。因此,从这个意义上讲,无符号数的运算优先级要高于有符号数,这一点对于应当频繁用到无符号数据类型的嵌入式系统来说是丰常重要的。 

首先进行一个实验,分别定义一个 signed int 型数据和 unsigned int 型数据,然后进行大小比较:

unsigned int a = 20;
signed int b = -130;

实验证明:$b > a$,也就是说$-130 > 20$,为什么会出现这样的结果呢?

这是因为在C语言操作中,如果遇到无符号数与有符号数之间的操作,编译器会自动转化为无符号数来进行处理,因此$a=20, b=4294967166$,这样比较下去当然$b > a$了。再举一个例子:

 unsigned int a = 20;
 signed int b = -130;
 std::cout << a + b << std::endl;

结果输出为$4294967186$。同样的道理:在运算之前,$a=20$,$b$被转化为$4294967166$,所以$a+b=42949671864,减法和乘法的运算结果类似。

如果作为 signed int 型数据的b=-130,b与立即数之间操作时不影响b的类型,运算结果仍然为 signed int 型:

signed int b = -130;
std::cout << b + 30 << std::endl;
// 输出为-100

而对于浮点数来说,浮点数 float, double 实际上都是有符号数, unsigned 和 signed 前缀不能加在 float 和 double 之上,当然就不存在有符号数根无符号数之间转化的问题了。

 示例

#include <iostream>
/*
当表达式中存在符号类型和无符号类型时
所有的操作数都自动转换为无符号类型
*/
using namespace std;
char getChar(int x,int y){
    char c;
    unsigned int a = x;
    unsigned int b = a + y;
    (a + y > 10)?(c = 1):(c = 2);
    return c;
}
void main(){
char c1 = getChar(7,4);
char c2 = getChar(7,3);
char c3 = getChar(7,-7);
char c4 = getChar(7,-8);
 
printf("c1=%d\n",c1);
printf("c2=%d\n",c2);
printf("c3=%d\n",c3);
printf("c4=%d\n",c4);
system("pause");
}
// 输出: c1=1  c2=2  c3=2  c4=1

规则总结

1、所有比 int 型小的数据类型,包括 char, signed char, unsigned char, short, signed short, unsigned short 转换为 int 型。如果转换后的数据会超出 int 型所能表示的范围的话,则转换为 unsigned int 型;
2、 bool 型转化为 int 型时, false 转化为0, true 转换为1;反过来所有的整数类型转化为 bool 时,0转化为 false ,其它非零值都转为 true ;
3、如果表达式中混有 unsigned short 和 int 型时,如果 int 型数据可以表示所有的 unsigned short 型的话,则将 unsigned short 类型的数据转换为 int 型,否则, unsigned short 类型及 int 型都转换为 unsigned int 类型。举个例子,在32位机上,int是32位,范围$-2,147,483,648 to 2,147,483,647$, unsigned short 是16位,范围$0 to 65,535$,这样 int 型的足够表示 unsigned short 类型的数据,因此在混有这两者的运算中, unsigned short 类型数据被转换为 int 型;
4、unsigned int 与 long 类型的转换规则同3,在32位机上, unsigned int 是32位,范围$0 to 4,294,967,295$, long 是32位,范围$-2,147,483,648 to 2,147,483,647$,可见 long 类型不够表示所有的 unsigned int 型,因此在混有 unsigned int 及 long 的表达式中,两者都被转换为 unsigned long ;
5、如果表达式中既有 int 又有 unsigned int ,则所有的 int 数据都被转化为 unsigned int 类型。

范例解析

unsigned int i = 3;
cout << i * -1;
// 输出?

各数据类型的表示范围

来自MSDN

补充说明:

1)在32位机上, int 型和 unsigned int 型都是32位(4个字节)。
2) enum 会跟据最大值来决定类型,一般来说为 int 型,如果超出 int 型所能表示的范围,则用比 int 型大的最小类型来表示( unsigned int, long 或者 unsigned long )。
3)关于类型的大小。一般用所能表示的数据范围来比较类型的大小,如 char 型< unsigned char 型< short 型...在表达式中,一般都是由小的类型向大的类型转换(强制类型转换除外)。

答案

输出是$4294967293$。
原因:在表达式$i * -1$中,$i$是 unsigned int 型,$-1$是 int 型(常量整数的类型同 enum ),按规则总结第5条可以知道$-1$必须转换为 unsigned int 型,即十六进制的0xFFFFFFFF,十进制的$4294967295$,然后再与$i$相乘,即$44294967295 * 3$,如果不考虑溢出的话,结果是$12884901885$,十六进制$0x2FFFFFFFD$,由于 unsigned int 只能表示32位,因此结果是0xFFFFFFFD,即十进制的$4294967293$。

(整理自网络)

参考资料:

https://blog.csdn.net/zhuimengzh/article/details/6728492

https://blog.csdn.net/miaouu/article/details/5213042