指针数组和数组指针

容易混淆，在中间加‘的’比较好理解，

即指针的数组（表示数组里面全是指针）；数组的指针（表示这个指针是指向数组的）。

目录

（1）指针数组：array of pointers，即用于存储指针的数组，也就是数组元素都是指针

（2）数组指针：a pointer to an array，即指向数组的指针

（3）USE

---

（1）指针数组：array of pointers，即用于存储指针的数组，也就是数组元素都是指针

int *p1[5]；
[]的优先级高于*，所以p1先与[]结合，表示p1是个数组，
“int*”修饰的是数组的内容，即数组的每个元素。
也就是说，该数组包含 5 个指向 int 类型数据的指针，
如下图，因此，它是一个指针数组。

如下代码，

char *arr[4] = {"hello", "world", "shannxi", "xian"};
//arr就是我定义的一个指针数组，它有四个元素，每个元素是一个char *类型的指针，这些指针存放着其对应字符串的首地址。

A:这个指针数组有多大呢？

答案是16个字节，因为它是一个指针数组。(这是废话，正话下面说) 每当出现这些问题时，脑子里一定要第一时间反应出内存映像图如下：

这里最左侧一列是一个很简陋但能说明意思的内存图，一般情况下，从栈区到代码区，是从高地址到低地址。栈向下增长，堆向上增长。

B:arr[4]是一个在主函数定义的数组。把它对应到对应到内存中，arr是一个在栈区,有四个元素的数组，而每一个数组又是一个指针，所以说它的四个元素各占四个字节，所以变量arr的大小是16个字节。

那么就有人问了？初始化arr的{“hello”, “world”, “shannxi”, “xian”};的是什么鬼？ 
这四个不是什么鬼，他们也存在在内存中，只是跟arr这个变量不在同一段空间，它们被分配在只读数据区，数组arr[4]的四个指针元素，分别存放着这四个字符串的首地址，想象一下，从栈区有四只无形的手指向数据区的空间。arr+1会跳过四个字节，。也就是一个指针的大小 ，这就相当与定义char *p1 = “hello”，char *p1 = “world”，char *p3 = “shannxi”， char *p4 = “xian”，这是四个指针，每个指针存放一个字符串首地址，然后用arr[4]这个数组分别存放这四个指针，就形成了指针数组。

（2）数组指针：a pointer to an array，即指向数组的指针

int (*p2)[5];
“()”的优先级比“[]”高，“*”号和 p2 构成一个指针的定义，指针变量名为 p2，而 int 修饰的是数组的内容，即数组的每个元素。
也就是说，p2 是一个指针，它指向一个int [5] 数据类型的数组，
如下图所示。很显然，它是一个数组指针，数组在这里并没有名字，是个匿名数组。

既然p2是一个指针，存放一个数组的地址，那么在我们定义一个数组时，数组名称就是这个数组的首地址，那么这二者有什么区别和联系呢？
int a[5];
a是一个长度为5的字符数组，a是这个数组的首元素首地址。既然a是地址，p2是指向数组的指针，那么能将a赋值给p2吗？

答案是不行的！因为a是数组首元素首地址，p2存放的却是数组首地址，

a是int类型，a+1，a的值会实实在在的加1，而p2是int [5]类型的，p2+1，p2则会加4，

虽然数组的首地址和首元素首地址的值相同，但是两者操作不同，

所以类型不匹配不能直接赋值（C语言中“=”语句需要俩边的数据类型一致，或者可进行隐形转换），但是可以这样：p2 = &a，p2相当与二维数组的行指针，现在它指向a[5]的地址。

（3）USE

char * msg[MSG_NUM] = {      //以下内容请自行修改
  {"乘客您好,欢迎乘坐"},
{"[n1]2[n0]路"},      //车次,采用单个数字变读(1读作幺)模式,读后恢复正常模式
  {"公交车,本路车由"},
{"开往"},
{",前门上车,后门下车,本车无人售票,请自备零钱"},
{"车辆起动,请站稳扶好"},
{"[2]车辆转弯,请注意安全"},
{"前方到站"},
{"下车的乘客后门请"},
{"车站到了,请您带好随身物品,从后门下车,谢谢您的乘坐,再见"},
{"始发站"},
{"终点站"},
{"soundk"},
{"到了"}

};

char型的指针数组；

在字符串的定义的时候用指针；

调用方式

void syn6288_SpeakStr(char *text,char MusicID)

例如    syn6288_SpeakStr(msg[12],0);
 

 

参考链接：

https://www.cnblogs.com/dan-Blog/articles/8866513.html

http://c.biancheng.net/view/335.html

https://blog.csdn.net/weibo1230123/article/details/81449593

https://blog.csdn.net/u011041241/article/details/51069573