嘿，我来唠唠这段时间折腾数组初始化的经历，踩了坑也捡了宝，分享给遇到类似情况的朋友～

背景：想偷懒的初始化方式 #

我本来不想写那些麻烦的文件解析代码（比如fopen()、fread()那一套），想直接让编译器帮我搞定数组初始化——把输入内容存在in.txt里，然后这么写代码：

#define MAX_ELEMENTS (20)
int a [ MAX_ELEMENTS ] = #include "in.txt";

但刚这么写就遇到两个核心问题：

• 怎么准确统计从文件里实际读入了多少个元素？
• 怎么让编译器把数组中没被文件初始化的剩余位置自动置0？

我的失败尝试：靠猜元素个数的笨办法 #

一开始我想了俩歪招，但都有致命缺陷：

• 从左到右数非零元素：如果文件里的元素本身就有0（比如中间某个值是0），直接就数错了
• 从右往左跳零找非零：要是文件最后几个元素就是0，或者编译器自动初始化的不是0（当时没吃透C标准，心里没底），这方法直接报废
• 最糟的假设：如果编译器自动初始化的剩余元素不是0，那我这俩思路全白搭

输了？也赢了？ #

结果是我既“输了”又“赢了”：

为啥说“输了”

1. 我的实际输入文件根本不是简单的一维数组，而是嵌套的复杂结构，比如：

{  {{1     },{100    },73},  {{1,5   },{  3,2  },14},  {{1,5,10},{ 10,2,1},23}}

之前的那些思路根本没法直接套用
2. 一开始的笨思路其实改改小bug也能用，但那是歪打正着，根本不是正确的解决办法

为啥说“赢了”

因为我学到了一个惊艳到爆的技巧！就是用sizeof的编译期计算来直接拿到文件里的元素总数：

sizeof ((int[]){   #include "in.txt"}) / sizeof (int)

虽然这行代码看起来有点“丑陋”，读起来费劲，但它完美解决了元素计数的问题——直接让编译器在编译阶段帮我们计算从文件中读入的元素总数，完全不用靠遍历猜值，简直是黑魔法！

另外关于剩余元素置零的问题，后来我才吃透C标准：如果数组在初始化时只提供了部分元素，那么未被初始化的剩余元素会被编译器自动置为0（不管是全局/静态数组，还是用=初始化的局部数组），这个问题其实根本不用额外操心，编译器会自动处理！

最后吐槽 #

现在最头疼的是选哪个答案当最佳——虽然@AlphinThomas是第一个回答的，但@Lundin的这个sizeof技巧太戳我了，真的很难抉择！