如何按C++17标准修复std::async引发的C4834编译器警告？

我正在修复C++代码库中的编译器C4834警告，触发原因是函数调用std::async但未捕获其返回的std::future对象。原始代码如下：

LONG WINAPI VexHandler(PEXCEPTION_POINTERS pExceptionPtrs)
{
    if (pExceptionPtrs->ExceptionRecord->ExceptionCode == EXCEPTION_STACK_OVERFLOW)
    {
        std::async(WriteMiniDumpWithActualJniContext, pExceptionPtrs);
        quick_exit(1);
    }
    else if (pExceptionPtrs->ExceptionRecord->ExceptionCode == EXCEPTION_BREAKPOINT)
    {
        WINDUMP_IMPLEMENTATION->WriteMiniDump(pExceptionPtrs);

        string exceptionInformation = GetExceptionsInformation(pExceptionPtrs);
        throw std::runtime_error(exceptionInformation);
    }

    return EXCEPTION_EXECUTE_HANDLER;
}

我尝试了两种修复方案：

方案一：捕获future并调用wait() #

...
if (pExceptionPtrs->ExceptionRecord->ExceptionCode == EXCEPTION_STACK_OVERFLOW)
{
    auto ftr = std::async(WriteMiniDumpWithActualJniContext, pExceptionPtrs);
    ftr.wait();
    quick_exit(1);
}
...

方案二：将返回值强制转换为void #

...
if (pExceptionPtrs->ExceptionRecord->ExceptionCode == EXCEPTION_STACK_OVERFLOW)
{
    static_cast<void>(std::async(WriteMiniDumpWithActualJniContext, pExceptionPtrs));
    quick_exit(1);
}
...

请问哪种方式更符合C++17标准？

解答 #

首先明确：C4834警告的本质是编译器提醒开发者，std::async返回的std::future临时对象被丢弃，而该对象的析构函数会阻塞至异步任务完成（当使用默认启动策略时）。两种方案都符合C++17标准，但在代码意图和可读性上有明显差异：

• 方案一的优势：
  显式捕获std::future并调用wait()，代码意图清晰明确——直接告诉维护者，我们需要等待异步生成minidump的任务完成后，再调用quick_exit(1)退出程序。这种写法完全贴合C++17标准的规范，同时遵循了良好的编码实践，避免了歧义。

• 方案二的局限：
  static_cast<void>仅用于抑制编译器警告，本质上临时std::future的析构仍会阻塞至任务完成，但代码意图模糊——其他开发者可能会误解为“不需要等待任务完成就退出”，或者只是为了消警告而编写的无意义代码。虽然它符合标准，但可读性和可维护性远不如方案一。

综上，方案一更符合C++17标准下的良好编码实践，优先推荐使用。

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