GCC不同优化级别下C++返回string_view代码的行为差异疑问

问题核心原因 #

你观察到的现象根源于get_value_worse实现本身存在未定义行为，和编译器优化规则的关系是派生的。

三目运算符的类型推导规则 #

C++标准中，三目运算符cond ? a : b的最终返回类型由两个分支操作数的共同类型推导决定：

• 你代码中三目运算符的第二个操作数是retrieved->second，类型为const std::string&
• 第三个操作数是""，类型为const char[1]，隐式转换后为const char*
  两个类型没有共同的引用类型，因此编译器会将两个操作数都转换为纯右值std::string：无论走哪个分支，都会生成一个临时的std::string对象，再用这个临时对象初始化返回的std::string_view。函数返回时临时对象生命周期结束，返回的std::string_view是悬垂的，访问其指向的内容属于未定义行为，标准不对其运行结果做任何约束。

-O0下的行为符合你的推测 #

无优化编译时，编译器会严格按照语法规则生成代码：三目运算符确实会生成栈上临时std::string，string_view指向该临时对象的内存，函数返回后临时对象析构，该内存位置的值是不确定的，和get_value_better返回的合法string_view（指向my_map中存活的std::string）比较结果为假，对应输出0。

-O3下的“正确”结果是未定义行为的巧合 #

C++标准的“不同优化级别可观测行为一致”要求仅针对符合标准规定的合法代码，存在未定义行为的代码不受该规则约束，编译器可以生成任意行为的二进制。
开启-O3时，编译器会对函数做内联优化，将get_value_worse的逻辑直接嵌入到main的调用位置，此时编译器可以追踪到三目运算符的结果最终只用于和另一个string_view比较，不需要生成额外的临时std::string，可以直接复用my_map中原有std::string的内存地址，因此看起来比较结果为真，但这只是特定编译器、特定优化参数下的偶然结果，不具备可移植性和可复现性。

补充说明get_value_better的合法性 #

get_value_better中两个return分支是独立的语句，不会做跨分支的类型统一：

• 第一个分支返回retrieved->second，直接将const std::string&转换为std::string_view，指向my_map中存活的字符串
• 第二个分支返回""，指向全局生命周期的字符串常量
  两个返回值都是合法的，没有悬垂问题，因此无论优化级别如何，其行为都是确定的。

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