获取数组大小时触发Undefined Behavior的问题求助

嘿，这个坑我踩过好多次！你遇到的确实和数组退化为指针的特性有关，所谓的**未定义行为（Undefined Behavior）**就是背后的元凶，咱们把这事掰扯清楚：

先看正常的情况：当你在数组定义的同一个作用域里写sizeof(arr)/sizeof(arr[0])时，编译器明确知道arr是数组类型，sizeof(arr)会返回整个数组占用的字节数，除以单个元素的字节数，自然能算出正确的元素个数。

但一旦把数组传到函数里，或者在宏里误用了指针，问题就来了：

• 函数参数的数组退化：C/C++里，数组作为函数参数时会自动退化为指向第一个元素的指针。比如你写void func(int arr[])，编译器实际会把它当成void func(int* arr)。这时候sizeof(arr)得到的是指针的字节数（32位系统是4，64位是8），再除以sizeof(int)（通常是4），结果要么是1要么是2。如果后续你用这个错误的大小去遍历数组，就会越界访问内存，读取到随机的垃圾值（比如你看到的4561033），这就是典型的未定义行为——标准没规定程序该怎么处理，结果完全不可控。
• 宏的文本替换陷阱：宏是预处理器直接做文本替换的，它分不清传入的是数组还是指针。比如你写#define ARRAY_SIZE(arr) sizeof(arr)/sizeof(arr[0])，如果传的是指针，宏会直接替换成sizeof(指针)/sizeof(指针[0])，同样会得到错误的数值，甚至如果指针是无效的，访问arr[0]本身就是未定义行为。

这里有几个靠谱的方案，根据你用的是C还是C++来选：

1. 最稳妥的通用方法：提前计算大小再传参 #

在数组定义的作用域里先算出正确的大小，然后把大小作为参数传给函数，从根源上避免数组退化的问题：

int arr[] = {1, 2, 3, 4, 5};
size_t arr_size = sizeof(arr) / sizeof(arr[0]);
// 把数组和大小一起传给函数
process_array(arr, arr_size);

2. C++专属：用模板函数推导数组大小 #

利用C++的模板特性，让编译器在编译期自动推导数组的大小，而且如果传的是指针，编译器会直接报错，从编译阶段就阻止错误：

template <typename T, size_t N>
size_t get_array_size(const T (&arr)[N]) {
    return N;
}

// 调用示例
int arr[] = {10, 20, 30};
size_t size = get_array_size(arr); // 得到3

3. C语言（C11及以后）：给宏加编译期检查 #

用_Static_assert和编译器内置的类型检查函数，确保宏只能接收数组类型，传指针的话直接编译报错：

#define ARRAY_SIZE(arr) \
    (sizeof(arr)/sizeof(arr[0]), \
     _Static_assert(!__builtin_types_compatible_p(typeof(arr), typeof(&arr[0])), "Error: Not an array!"), \
     sizeof(arr)/sizeof(arr[0]))

4. C++17及以后：用标准库的std::size #

直接用标准库提供的std::size函数，安全又省心，还能兼容各种容器：

#include <iterator>

int arr[] = {1, 2, 3};
auto size = std::size(arr); // 得到3

简单来说，未定义行为就是C/C++标准没有对这种情况的程序行为做任何规定——编译器可以随便处理，比如输出奇怪的数值、程序崩溃、甚至看起来正常但背地里破坏了内存。你看到的4561033就是越界访问内存后读取到的随机垃圾值，属于未定义行为的典型表现。这类问题最危险的地方在于，有时候程序看起来能正常运行，但实际上已经埋下了隐患，在不同环境下可能突然崩溃。

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