为何对数组指针解引用得到指向首元素的指针，而非完整数组对象？

第一步：明确指针本身的类型定义 #

• 代码中int(*pi)[3]是典型的指向长度为3的int型数组的数组指针，它存储的是整个num数组的起始内存地址，和直接取&num的地址值完全相等。
• 按照指针解引用的基础规则，对该指针执行*pi操作时，得到的静态类型本质上是int[3]的完整数组对象，并非天生就返回指向首元素的指针。

第二步：核心触发机制——数组到指针的隐式退化 #

• C/C++标准明确规定：当原生数组类型出现在普通表达式语境中，且不满足三类例外条件时，会被自动转换为指向其首元素的指针（即数组到指针的退化解引用）：
  • 作为sizeof运算符的操作数
  • 作为取址&运算符的操作数
  • 作为字符串字面量初始化字符数组的场景
• 回到示例代码，std::cout << *pi这个表达式里，*pi对应的完整int[3]数组类型，没有匹配的std::ostream流输出运算符重载，因此触发了隐式退化，被转换为类型为int*的首元素指针。流操作自然就输出了这个指针存储的内存地址——由于数组首元素的内存位置就在数组整体的内存块开头，所以你看到的输出值和pi本身存储的地址值是完全一样的，才会造成“解引用后输出还是地址”的观感。

为什么不会默认输出数组全部元素 #

• C++的标准输出流std::ostream从来没有为原生C风格数组提供默认的打印重载，不存在“传入一个数组就自动循环输出所有元素”的内置行为，这也是预期和实际输出出现偏差的直接原因。
• 要验证解引用得到的确实是完整数组对象，可以通过下标访问直接读取元素值：比如执行std::cout << (*pi)[0] << " " << (*pi)[1] << " " << (*pi)[2];，就能正常输出66 77 88。这里的访问逻辑和普通数组名的下标访问规则完全一致——本质就是利用了解引用得到的完整数组对象的下标运算能力。

常见认知误区澄清 #

• 不存在“对数组指针解引用直接得到首元素指针”的内置规则，只是数组在表达式中的自动退化机制，制造了“解引用结果就是指针”的错觉。
• 只要绕开退化触发条件，就能拿到完整的数组对象信息：比如以数组引用的形式接收解引用结果，就可以正常获取数组的长度、遍历全部元素，不会丢失数组的长度等类型信息。

内容的提问来源于stack exchange，提问作者air