C语言运算中的数据类型自动转换原则

古城微笑少年丶 2023-06-30 10:51 69阅读 0赞

**1、隐式转换**  
**    **C在以下四种情况下会进行隐式转换:  
       1、算术运算式中，低类型能够转换为高类型。  
       2、赋值表达式中，右边表达式的值自动隐式转换为左边变量的类型，并赋值给他。  
       3、函数调用中参数传递时，系统隐式地将实参转换为形参的类型后，赋给形参。  
       4、函数有返回值时，系统将隐式地将返回表达式类型转换为返回值类型，赋值给调用函数。  
  
2、**算数运算的隐式转换**  
    算数运算中，首先有如下类型转换规则：  
       1、字符必须先转换为整数(C语言规定字符类型数据和整型数据之间可以通用) 。  
       2、short型转换为int型(同属于整型) 。  
       3、float型数据在运算时一律转换为双精度(double)型，以提高运算精度(同属于实型) 。  
    其次，有下面的规则。

当不同类型的数据进行操作时，应当首先将其转换成相同的数据类型，然后进行操作，转换规则是由低级向高级转换。转换规则如下图所示:

![aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAyMTc5UFdyUS5naWY][]

有符号数与无符号数之间运算问题  
以下实验均在virual c++6中运行通过  
这个问题测试是否懂得C语言中的**整数自动转换原则**，有些开发者懂得极少这些东西。当表达式中存在有符号类型和无符号类型时所有的操作数都自动转换为**无符号类型**。因此，从这个意义上讲，无符号数的运算优先级要高于有符号数，这一点对于应当频繁用到无符号数据类型的嵌入式系统来说是丰常重要的。   
首先进行一个实验，分别定义一个signed int型数据和unsigned int型数据，然后进行大小比较：  
    unsigned int a=20;  
    signed int b=-130;  
a>b?还是b>a？实验证明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＝4294967186

减法和乘法的运算结果类似。  
  
如果作为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

这样一个题，据说是微软面试题：   
unsigned int i=3;  
cout<<i \* -1;  
问结果是多少。

第一反应：-3。不过结果似乎不是这样的，写了个程序，运行了一下，发现是：4294967293。很诡异的一个数字，怎么也想不明白为什么会是这么个奇怪的数字。但是在我发现这数的十六进制数是FFFFFFFD时，我想我已经离答案很近了...  
   
这个涉及到了混合着不同数据类型的表达式中的数据类型的转换问题。在总结转换问题之前，先说明一下各种数据类型（只说明numeric类型的），下表来自MSDN：  
![aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAxOTgxZFJSdS5naWY][]

对上表补充说明一下：  
1）在32位机上，int型和unsigned int型都是32位的（4个字节）。  
2）enum会跟据最大值来决定类型，一般来说为int型，如果超出int型所能表示的范围，则用比int型大的最小类型来表示（unsigned int, long 或者unsigned long）  
3）关于类型的大小。一般用所能表示的数据范围来比较类型的大小，如char型<unsigned char型<short型...在表达式中，一般都是由小的类型向大的类型转换（强制类型转换除外）  
   
下面结合自己查的资料，加上自己不断地举各种情况编程，总结一下关于类型转换（仅限于算术表达式中关于整数类型的转换）的一些问题（如有缺漏，欢迎补充，感激不尽）  
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类型。  
   
经过这番总结，前面提出的问题的答案应该就很明显了吧。在表达式i\*-1中，i是unsigned int型，-1是int型（常量整数的类型同enum），按第5条可以知道-1必须转换为unsigned int型，即0xffffffff，十进制的4294967295，然后再与i相乘，即4294967295\*3，如果不考虑溢出的话，结果是12884901885，十六进制0x2FFFFFFFD，由于unsigned  
 int只能表示32位，因此结果是0xfffffffd，即4294967293。

参考：  
http://blog.csdn.net/miaouu/article/details/5213042  
http://blog.csdn.net/ysuncn/article/details/1787189  
http://blog.sina.com.cn/s/blog\_590be5290100htvu.html

[aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAyMTc5UFdyUS5naWY]: https://imgconvert.csdnimg.cn/aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAyMTc5UFdyUS5naWY
[aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAxOTgxZFJSdS5naWY]: https://imgconvert.csdnimg.cn/aHR0cDovL2hpLmNzZG4ubmV0L2F0dGFjaG1lbnQvMjAxMTA5LzcvMF8xMzE1NDAxOTgxZFJSdS5naWY