为何传递const char[N]与const char*给view::c_str()会生成不同二进制，而string_view则不会？

这问题问到点子上了——底层优化里，编译期信息 vs 运行时计算的差异往往就是性能的关键，咱们来掰扯清楚：

先拆解两种场景的汇编差异根源 #

首先得搞明白为什么会出现不同的汇编输出：

• 场景1：std::string_view传const char[N]/const char*，汇编一致
  当你传const char[N]（比如const char str[] = "hello"）时，编译器在编译期就明确知道数组的长度，std::string_view构造时直接拿到这个编译期常量长度；如果传的是指向字符串字面量的const char*（比如const char* str = "hello"），现代编译器会做常量折叠优化，能识别出这个指针指向的是编译期已知的字符串常量，同样可以在编译期算出长度。最终std::string_view都会生成一个「已知长度的视图」，range::for_each遍历的时候直接用固定长度生成循环，不需要额外运行时计算。

• 场景2：ranges::view::c_str()传const char[N]/const char*，汇编不同
  传const char[N]时，编译器同样能拿到编译期长度，c_str()生成的视图直接复用这个固定长度，遍历逻辑和std::string_view完全一致；但如果传的是const char*，编译器没法确定这个指针指向的是编译期常量还是动态分配的字符串（比如堆上new出来的），所以c_str()必须在运行时调用strlen计算字符串长度——这就多了一次遍历字符串的开销，生成的汇编会包含strlen的调用逻辑，以及基于运行时长度的循环，和固定长度的循环汇编自然不同。

哪种汇编更优？结论很明确 #

不需要运行时计算长度的汇编（也就是传const char[N]的两种场景、以及std::string_view传const char*的场景）更优，核心原因有两个：

1. 避免额外的strlen开销：strlen需要从字符串开头遍历到'\0'，是O(n)的额外时间，短字符串影响不大，但长字符串或高频调用场景下，累积开销会很可观；
2. 编译器优化空间更大：知道固定长度后，编译器可以生成更紧凑的循环代码——比如循环展开、减少边界检查，甚至极端情况下把整个遍历逻辑内联；而基于运行时长度的循环，因为长度是未知的，很多编译期优化都没法做，生成的指令会更复杂。

举个直观的例子：固定长度循环可能直接生成for (int i=0; i<5; ++i)的机器码，而运行时长度的循环，得先调用strlen拿到长度，再生成for (int i=0; i<len; ++i)，不仅多了一次遍历，循环指令的效率也更低。

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