为何三元运算符返回字符串生成的代码与等价if/else差异显著？

哇，这个发现真的挺有意思的！我来帮你拆解一下背后的原因，核心问题确实出在字符串字面量的类型推导和编译器对不同代码结构的优化策略上。

首先，我们先明确两个代码片段的本质差异：

• 当你写return b ? "Hello" : "Stack-overflow";时，三元运算符的两个操作数都是const char[]类型。C++规则里，不同长度的数组在三元运算符中会被统一推导为const char*（数组退化为指针），而不是直接推导为std::string。这意味着编译器需要先把这个指针转换成std::string，这个转换过程就带来了额外的开销。
• 而if/else版本里，每个return "xxx"都是直接调用std::string的构造函数（从const char*），编译器可以针对每个分支做极致的优化——因为每个分支的字符串是完全已知的，它可以直接把字符串的字节硬编码到汇编里，跳过通用的内存复制逻辑。

拆解第一个示例的冗余汇编 #

我们来看Clang为三元运算符生成的代码：

• 你注意到的add rdi, 16是在设置std::string的内部缓冲区（因为小字符串优化SSO，std::string的前16字节是指针和长度，后面是SSO缓冲区）。
• 关于长度计算：lea r14, [rcx + 8*rcx] + add r14,5其实是Clang在编译期就计算好两个字符串的长度——当b为true时，rcx是0，结果是5（"Hello"的长度）；当b为false时，rcx是1，结果是14（"Stack-Overflow"的长度），所以它不用调用strlen，这是Clang的一个小优化，但依然绕不开通用复制。
• 调用memcpy是因为编译器此时拿到的是一个const char*，它需要把指针指向的字符串内容复制到std::string的SSO缓冲区里。虽然字符串是编译期已知的，但因为三元运算符的统一类型是指针，编译器没法像if/else那样直接在每个分支硬编码字节，只能走通用的内存复制流程。

为什么if/else和显式构造的三元运算符更高效？ #

• 对于if/else版本，编译器可以完全拆分每个分支：当b为true时，直接把"Hello"的字节按顺序写入std::string的缓冲区（比如mov dword ptr [rcx], 1819043144其实是"Hell"的ASCII值，mov word ptr [rcx + 4], 111是'o'），然后设置长度为5，直接返回。完全不需要调用任何库函数。
• 当你显式写return b ? std::string("Hello") : std::string("Stack-Overflow");时，三元运算符的两个操作数都是std::string类型，编译器可以针对每个std::string的构造做优化，和if/else的逻辑完全一致——它知道每个分支的字符串内容，直接硬编码写入缓冲区，跳过通用复制。

关于GCC的差异 #

GCC在第一个示例中调用strlen，是因为它的优化策略不同：它没有像Clang那样在编译期计算字符串长度，而是选择调用strlen来获取指针指向的字符串长度，这也是一种通用处理方式，但效率不如Clang的编译期计算，当然也不如if/else的直接硬编码。

总结一下：问题的核心是三元运算符对数组字面量的类型推导导致退化为指针，使得编译器无法像if/else那样针对每个分支做极致的展开优化。显式构造std::string可以让三元运算符的类型统一为std::string，从而触发和if/else一样的高效优化。

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