C语言
首发于C语言

C语言关键字 -(typedef关键字)

1、来个笑话


赵本山在春晚有一个这样的笑话,是这样的

有一只老虎,被蛇咬了一口,老虎急了,就想把这蛇踩死,追啊追追追,追到一个小河边,这蛇钻水里去了,老虎就在河岸上就这么等,老虎说,小样的我就不信你不出来。不一会,从里面钻出来一只王八,老虎上去就把它按住了,“小样的你穿个马甲(jiá)我就不认识你了?”

这就是那只小乌龟

typedef关键字就是擅长做障眼法,任何其他类型遇上他就可以变身成其他的模样,这么厉害的关键字,我们可一定要供着,因为实在太牛了。


2、typedef 或者应该是typealias


typedef 从字面理解应该是type + define 意思就是重新定义数据类型,不过这种理解不正确,我们在学习Linux ,知道里面有一个单词叫做alias,就是别名的意思,把type理解成typealias就再好不过了。比如姚明,我们给他起了个别名叫做中国的巨人,或者科比,我们给他起了个别名叫做黑曼巴。

我们在做项目的时候,我们需要把很多数据类型放在一起,然后起一个新的名字,这个时候就需要typedef例如:

 typedef struct player
 {
     //code
 }Play_st,*Play_p;
 
A),struct player play1;和 Play_st play1;是一样的
B),struct player *play2;和Play_p play2; Play_st *play2;是一样的

大家对B的答案不知道有没有疑惑,我们可以这样理解,typedef AAAA BBBB;就是把AAAA的别名定义为BBBB,所以上面的,我们可以这样理解

struct player {//code} 的别名是Play_st;

struct player {//code} * 的别名是Play_p;


3、typedef 和存储类关键字(storage class specifier)

这种说法是不是有点令人惊讶,typedef 就像 auto,extern,mutable,static,和 register 一样,是一个存储类关键字。这并不是说 typedef 会真正影响对象的存储特性;它只是说在语句构成上,typedef 声明看起来象 static,extern 等类型的变量声明。下面将带到一个陷阱:


  typedef static int FAST_COUNTER; // 错误

  编译通不过。问题出在你不能在声明中有多个存储类关键字。因为符号 typedef 已经占据了存储类关键字的位置,在 typedef 声明中不能用 static(或任何其它存储类关键字)。


4、用typedef来定义与平台无关的类型

比如定义一个叫 REAL 的浮点类型,在目标平台一上,让它表示最高精度的类型为:

typedef long double REAL;

在不支持 long double 的平台二上,改为:

typedef double REAL;

在连 double 都不支持的平台三上,改为:

typedef float REAL;

也就是说,当跨平台时,只要改下 typedef 本身就行,不用对其他源码做任何修改。

标准库就广泛使用了这个技巧,比如size_t。另外,因为typedef是定义了一种类型的新别名,不是简单的字符串替换,所以它比宏来得稳健。
这个优点在我们写代码的过程中可以减少不少代码量哦,做嵌入式开发的同学,对于自己的一份驱动代码,代码如果写的好的话,可以同时移植到其他平台就非常容易。


5、为复杂的声明定义一个新的简单的别名

方法是:在原来的声明里逐步用别名替换一部分复杂声明,如此循环,把带变量名的部分留到最后替换,得到的就是原声明的最简化版。

例子一:

原声明:void (*b[10]) (void (*)());

变量名为b,先替换右边部分括号里的,pFunParam为别名一:

typedef void (*pFunParam)();

再替换左边的变量b,pFunx为别名二:

typedef void (*pFunx)(pFunParam);

原声明的最简化版:

pFunx b[10];

例子二:

原声明:doube(*)() (*e)[9];

变量名为e,先替换左边部分,pFuny为别名一:

typedef double(*pFuny)();

再替换右边的变量e,pFunParamy为别名二

typedef pFuny (*pFunParamy)[9];

原声明的最简化版:

pFunParamy e;

理解复杂声明可用的“右左法则”:从变量名看起,先往右,再往左,碰到一个圆括号

就调转阅读的方向;括号内分析完就跳出括号,还是按先右后左的顺序,如此循环,直

到整个声明分析完。

举例:

int (*func)(int *p);

首先找到变量名func,外面有一对圆括号,而且左边是一个*号,这说明func是一个指针;然后跳出这个圆括号,先看右边,又遇到圆括号,这说明(*func)是一个函数,所以func是一个指向这类函数的指针,即函数指针,这类函数具有int*类型的形参,返回值类型是int。

int (*func[5])(int *);

func右边是一个[]运算符,说明func是具有5个元素的数组;func的左边有一个*,说明func的元素是指针(注意这里的*不是修饰func,而是修饰func[5]的,原因是[]运算符优先级比*高,func先跟[]结合)。跳出这个括号,看右边,又遇到圆括号,说明func数组的元素是函数类型的指针,它指向的函数具有int*类型的形参,返回值类型为int。

这种用法是比较复杂的,出现的频率也不少,往往在看到这样的用法却不能理解,相信以上的解释能有所帮助。


6、typedef 与#define 的区别

案例一:

通常讲,typedef要比#define要好,特别是在有指针的场合。请看例子:

typedef char *pStr1;
#define pStr2 char *;
pStr1 s1, s2;
pStr2 s3, s4;

在上述的变量定义中,s1、s2、s3都被定义为char *,而s4则定义成了char,不是我们

所预期的指针变量,根本原因就在于#define只是简单的字符串替换而typedef则是为一

个类型起新名字。

案例二:

下面的代码中编译器会报一个错误,你知道是哪个语句错了吗?

#include "stdio.h"

void main(void)
{
	typedef char * pStr;
	
	char string[4] = "abc";
	const char *p1 = string;
	const pStr p2 = string;
	
	p1++;
	p2++;
}

是p2++出错了。这个问题再一次提醒我们:typedef和#define不同,它不是简单的文本替换。上述代码中const pStr p2并不等于const char * p2。const pStr p2和const long x本质上没有区别,都是对变量进行只读限制,只不过此处变量p2的数据类型是我们自己定义的而不是系统固有类型而已。因此,const pStr p2的含义是:限定数据类型为char *的变量p2为只读,因此p2++错误。

那么问题来了,为什么p1++,没有问题,p1++前面也有一个const,

#include "stdio.h"

void main(void)
{
	typedef char * pStr;
	
	char string[4] = "abc";
	const char *p1 = string;
	const pStr p2 = string;
	
	p1++;
	//p2++;
	printf("%s\n",p1);
}

这就涉及下面这个概念

//const和类型的位置可以互换,如果类型为指针则不能随意互换

比如:

const int i; 和 int const i; 这个是一样的

所以我们在看看上面两个语句

typedef char * pStr;

char string[4] ="abc";

const char *p1 = string; //p1 是一个指针,p1指向的值是一个const char 类型的,但是p1的值可以改变

const pStr p2 = string; //pStr本身是一个数据类型,你现在可以把pStr替换成int,这里const限定的是p2的值不能被改变,所以p2++出错。

我们把上面的代码改成下面的

#include "stdio.h"

void main(void)
{
	typedef char * pStr;
	
	char string[4] = "abc";
	 char * const p1 = string;
	const pStr p2 = string;
	
	p1++;
	//p2++;
	printf("%s\n",p1);
}

所以总结const修饰指针变量

const int *a;//修饰指向的对象(*a),*a不可变,指针a可变
int const *a;//修饰指向的对象(*a),*a不可变,指针a可变
int * const a;//修饰指针(a),a不可变,指针指向的对象*a可变
const int * const a; //指针指向的对象*a不可变,指针a不可变



如果觉得有帮助,请帮忙关注公众号【嵌入式Linux】

编辑于 2018-11-11

文章被以下专栏收录