MSVC下C++20中DirectX12资源屏障报C2102错误的原因与应对方案

触发编译错误：error C2102: '&' requires l-value

• CD3DX12_RESOURCE_BARRIER::Transition是D3D12辅助库提供的静态方法，调用后返回的是一个纯右值临时对象——既没有具名标识符，也不属于程序中可寻址的持久化变量，生命周期仅存在于当前语句的执行周期内。
• 按照C++语言的通用规则，取地址运算符&的操作数必须是左值，从标准层面就不允许直接对纯右值临时对象取地址。
• C17模式下可正常编译的核心原因，是MSVC为了兼容Win32生态中积累的大量旧式遗留代码，默认开启了“允许对临时对象取址”的非标准兼容口子。在C20特性全面落地前，哪怕开启C++17标准对齐开关，这个兼容扩展也不会被强制关闭，因此原有写法可以绕过标准检查正常编译。
• C20模式下抛出错误的原因，是MSVC对齐最新C工作草案的严格合规检查后，这个历史兼容扩展被默认关闭，直接暴露了原写法违反通用标准规则的本质，因此触发编译错误。

原写法能长期稳定运行，并不是因为写法本身符合规范：

• 哪怕在编译器扩展允许取址的场景下，C++标准也明确规定纯右值临时对象的生命周期会持续到所在全表达式执行完成。也就是说，在ResourceBarrier函数内部读取指针指向的屏障参数时，临时对象依然处于有效状态，不存在悬空指针的未定义行为。
• 但这个写法从始至终都不是可移植的标准C代码，完全依赖MSVC的私有扩展，换用Clang、GCC等其他编译器，从C11标准开始就无法通过编译。

完全不需要回退使用C++17标准，只需要把静态方法返回的临时对象显式存储到一个具名的栈上左值变量中，再对该变量取地址即可：

• 旧的非标准写法（C++20下编译失败）：
  m_commandList->ResourceBarrier(1, &CD3DX12_RESOURCE_BARRIER::Transition(pResource, currState, nextState));
• 跨编译器、跨C++版本兼容的标准写法：

  CD3DX12_RESOURCE_BARRIER barrier = CD3DX12_RESOURCE_BARRIER::Transition(pResource, currState, nextState);
  m_commandList->ResourceBarrier(1, &barrier);
  

• 该写法无任何额外运行时开销：CD3DX12_RESOURCE_BARRIER本身是无自定义构造逻辑的纯结构体，编译器会对两段代码生成完全一致的栈布局和目标汇编指令，不存在多余的对象拷贝或性能损耗。

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