传递连续数组：选指针+数组大小还是首尾指针？

在设计接收连续数组的C语言函数时，两种传参方式各有优劣，不存在绝对的“正确答案”，但可以根据场景和需求做选择：

两种方式的核心逻辑 #

• 方式A（指针+大小）：void foo(int* arr, size_t size);
  直接传递数组起始指针和元素总数，逻辑贴合“处理N个元素”的日常思维。
• 方式B（首指针+尾指针）：void foo(int* arrBegin, int* arrEnd);
  通过首尾指针（尾指针指向最后一个元素的下一个位置）划定区间，更贴合指针迭代的底层逻辑。

适用场景对比 #

优先选方式A的场景 #

• 天然知晓元素总数：比如从用户输入、配置中直接拿到元素数量，直接传size比计算尾指针更直观，减少额外操作。
• 函数频繁依赖元素总数：例如计算总和、平均值，或需要基于元素序号做判断的逻辑，不用每次计算arrEnd - arrBegin，代码可读性更高。
• 兼容传统C API：C标准库（如memcpy、memset）大多采用指针+大小的设计，风格统一能降低团队认知成本。

优先选方式B的场景 #

• 基于指针迭代的操作：比如遍历过滤、元素转换，循环条件可以直接写while (arrBegin != arrEnd)，无需维护计数器，代码更简洁。
• 处理数组子区间：只需传入子区间的首尾指针（如arr+2和arr+8），不用额外计算子区间大小，避免“起始下标+大小”的计算错误。
• 对齐C迭代器风格：如果是C/C混合项目，或未来可能迁移到C++，首尾指针的设计和STL容器迭代器逻辑一致，降低切换成本。

各自的弊端 #

方式A的问题 #

• 越界风险高：如果传入的size与数组实际长度不匹配，函数内部无法验证，直接访问会触发未定义行为。
• 子区间处理繁琐：需要手动计算子区间的起始指针和大小，容易出现偏移量计算错误。

方式B的问题 #

• 无法直接获取元素总数：若函数需要元素个数，必须计算arrEnd - arrBegin，如果传入的指针不属于同一连续数组，计算结果无意义。
• 新手易误解：刚接触C的开发者可能会把尾指针当成最后一个元素的地址，导致循环少执行一次或越界。
• 兼容传统API不便：函数内部调用memcpy等需要大小的接口时，必须先计算区间长度，多一步转换操作。

总结 #

无需刻意纠结“最优解”，优先统一项目现有风格是最高效的选择。如果是新项目，可根据核心场景判断：偏向传统业务逻辑选A，偏向算法迭代选B。无论用哪种，都要确保参数的正确性：

• 用方式A时，保证size与数组实际长度一致；
• 用方式B时，保证arrBegin和arrEnd属于同一连续数组，且arrBegin <= arrEnd。

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