C++析构函数中访问函数返回值出现异常行为的问题咨询

示例代码如下，预期行为：无论是否定义IS_ERR宏，~X()析构函数执行时，捕获的局部变量ptr都应当不为空

#include <iostream>
#include <functional>
#include <vector>
#include <memory>

struct X {
    X(std::function<void()> f): f_{std::move(f)} {}

    ~X() {
        f_();
    }

    std::function<void()> f_;
};

std::shared_ptr<int> func() {
    std::shared_ptr<int> ptr;

    X x([&] {
        std::cout << "dtor, ptr == null? " << (ptr == nullptr) << ", addr " << (long long)(&ptr) << std::endl;
    });

    if (ptr = std::make_shared<int>(100)) {
        std::cout << "return, ptr == null? " << (ptr == nullptr) << ", addr " << (long long)(&ptr) << std::endl;
        return ptr;
    }

#if defined(IS_ERR)
    return nullptr;
    // return, ptr == null? 0, addr 140732821766368
    // dtor, ptr == null? 1, addr 140732821766368 // 注意：此处ptr为空！即便调用方未接收返回值，ptr的内部资源也会在X析构前被移动到调用方返回值存储区
    // fini, ptr == null? 0, addr 140732821766576
#else
    // return, ptr == null? 0, addr 140732879315376
    // dtor, ptr == null? 0, addr 140732879315376 // 注意：此处ptr不为空，符合预期
    // fini, ptr == null? 0, addr 140732879315376
    return ptr;
#endif
}

int main()
{
    auto ptr = func();
    std::cout << "fini, ptr == null? " << (ptr == nullptr) << ", addr " << (long long)(&ptr) << std::endl;
}

两种场景的表现差异：

• 定义IS_ERR宏的场景：X析构时ptr为空，即便调用方没有额外处理返回值，ptr的内部资源也会在X的析构函数执行前被移动到调用方的返回值存储区域。
• 未定义IS_ERR宏的场景：X析构时ptr不为空，符合预期。

测试使用的编译器版本：

g++ --version : g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0

两种编译器下，无论是否开启O3优化，测试结果完全一致：
Clang测试输出：

rm -f test && clang++ -o test test.cc -std=c++11  -Wno-parentheses && ./test | grep dtor    
dtor, ptr == null? 0, addr 140732827398560
rm -f test && clang++ -o test test.cc -std=c++11    -DIS_ERR  -Wno-parentheses && ./test | grep dtor   
dtor, ptr == null? 1, addr 140732832612560
rm -f test && clang++ -o test test.cc -std=c++11 -O3  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 0, addr 140732887884168
rm -f test && clang++ -o test test.cc -std=c++11  -O3  -DIS_ERR  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 1, addr 140732702822624

GCC测试输出：

rm -f test && g++ -o test test.cc -std=c++11  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 0, addr 140735881081728
rm -f test && g++ -o test test.cc -std=c++11    -DIS_ERR  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 1, addr 140722084209920
rm -f test && g++ -o test test.cc -std=c++11 -O3  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 0, addr 140736717254624
rm -f test && g++ -o test test.cc -std=c++11  -O3  -DIS_ERR  -Wno-parentheses && ./test | grep dtor
dtor, ptr == null? 1, addr 140735485800352

该问题的实际业务场景多出现于Go风格的错误传播、RAII守卫逻辑中，示例如下：

using Error = std::shared_ptr<std::string>;
// 模拟Go风格的错误传播逻辑

Error func() {
  Error err;
 
    X x([&] {
        if (err) {
          // 执行日志记录、告警触发等错误处理逻辑
        } else {
         // 执行核心关键逻辑，如快递下发、资金转账等
         // 如果err非空却被误判为空，会触发无错误时才允许执行的操作，引发灾难性后果
        }
    });
 err = doSomeThing();
if (err) {
  err = Wrap(err, "do func");
  return err;
}
#if defined(IS_ERR)
  return nullptr;
#else
  return err;
#endif
}  

一旦触发上述异常行为，析构阶段的错误校验会完全失效：实际返回错误时，捕获的err已经被移走变为空值，逻辑会误判为执行成功，触发高风险操作。

该行为是C++标准规定的语义，不属于编译器bug，核心由两个规则共同导致：

1. 函数退出的固定执行顺序：函数执行return语句时，会首先将返回值拷贝/移动构造到调用方预留的返回值存储区域，完成返回值构造后，才会按照「局部变量声明顺序的逆序」销毁栈上所有局部对象。
2. 具名返回值优化（NRVO）的触发限制：只有当函数所有返回路径都返回同一个具名局部自动变量时，编译器才可以合法触发NRVO——直接将该局部变量的存储地址与调用方返回值存储地址重合，省略返回时的移动/拷贝操作，此时局部变量本身就是返回值对象，不存在移动后变空的问题。

两种场景的差异完全来自NRVO是否触发：

• 未定义IS_ERR时，函数所有return分支返回的都是同一个局部变量ptr，满足NRVO触发条件，return时不需要移动ptr的内部资源，后续析构X时ptr仍然持有原对象，表现符合预期。
• 定义IS_ERR时，函数存在两个不同的返回表达式：if分支返回ptr，外层分支返回nullptr，编译器判定不满足NRVO触发条件，会生成独立的返回值存储。执行if分支的return ptr时，首先会将局部ptr的内容移动构造到返回值存储，移动完成后局部ptr就变成空的shared_ptr；之后才会按逆序析构局部变量（先析构X，再析构局部ptr），因此X析构时读取到的ptr已经是空值。

注意：哪怕外层的return nullptr分支实际上永远不会被执行（std::make_shared正常情况下不会返回空指针，if条件恒真），只要编译器在语义分析阶段识别到存在不同的返回表达式，就会禁用NRVO，这也是不可达分支能改变程序运行时行为的原因。

• 不要在RAII析构逻辑（包括析构时执行的lambda回调、作用域守卫）中，直接依赖被返回的局部变量的状态。如果需要在析构时判断执行结果，应当用独立的、不会被移动的基础类型标记变量（比如bool has_error）记录状态，析构逻辑只读取该标记，不访问会被当作返回值移动的对象。
• 高风险逻辑不要完全依赖析构时的隐式状态判断，可以给RAII守卫提供显式的Commit()/Rollback()接口，在return语句前手动调用接口明确标记状态，避免隐式的编译器行为改变判断结果。
• 尽量保持函数所有返回路径返回同一个具名局部变量，避免在不同分支返回字面量、临时对象等不同表达式，防止意外禁用NRVO。比如上述IS_ERR场景，不要直接写return nullptr;，改为先给局部变量赋值ptr = nullptr;再统一return ptr;，即可正常触发NRVO，避免提前移动的问题。
• 不要假设局部变量的析构发生在返回值构造之前，所有依赖局部变量状态的逻辑，如果需要在返回前执行，尽量显式写在return语句之前，不要延迟到局部对象析构阶段。

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