应使用std::result_of<F(std::declval<Args>()...)>::type，必须对每个参数用std::declval，函数类型F需可调用且不能是重载名或未定义模板别名。

std::result_of 在 C++11/14 中怎么写才不报错？

它早被弃用了，但老项目里躲不开。关键不是“怎么用”，而是“怎么写才让编译器不吐 std::result_of<f>::type</f> 未定义”。

常见错误现象：error: 'type' in 'struct std::result_of<...>' does not name a type</...> —— 这几乎全是参数类型没加 std::declval 导致的。

• 必须对每个参数用 std::declval<arg>()</arg>，不能直接写 Arg；比如 std::result_of<f double>::type</f> 是错的，得写成 std::result_of<f>(), std::declval<double>())>::type</double></f>
• 函数类型 F 必须可调用：普通函数指针、成员函数指针、functor 类型都行，但不能是重载函数名（会歧义），也不能是未定义的模板别名
• 如果 F 是成员函数指针，第一个参数得是对象（或指针）类型，例如 std::result_of<decltype int>::type</decltype> 要写成 std::result_of<decltype>(), std::declval<int>())>::type</int></decltype>

为什么 std::result_of 会被 std::invoke_result 替代？

根本原因：std::result_of 的 SFINAE 友好性差，且语义模糊 —— 它试图模拟“调用”，但实际依赖的是一个过时的可调用性检测规则（C++11 初版），遇到引用折叠、cv 限定符、返回引用等场景容易崩。

典型兼容性影响：

立即学习“C++免费学习笔记（深入）”；

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• std::result_of<f></f> 在某些编译器（如旧版 GCC）里无法推导右值引用调用结果
• 对 noexcept 函数或返回 auto 的 lambda，std::result_of 常静默失败，而 std::invoke_result 明确支持
• C++17 起，std::result_of 标准中被标记为 deprecated，Clang 10+ 和 GCC 9+ 默认开启 -Wdeprecated-declarations 警告

在 C++14 项目里安全迁移到 invoke_result 的最小改动

不是所有地方都能立刻升 C++17，但可以靠 std::invoke_result_t 的别名兼容层绕过去 —— 关键是别自己实现，用标准库已提供的兜底。

实操建议：

• 头文件必须加 #include <type_traits>（C++11 就有，但 std::invoke_result 需 C++17；不过你可以用条件编译 + 自定义别名）
• 若编译器支持 C++17，直接用 std::invoke_result_t<f args...></f>，它不要求 std::declval，参数类型直写即可
• 若只能用 C++14，定义兼容宏：

  #if __cplusplus >= 201703L
      using result_type = std::invoke_result_t<F, Args...>;
  #else
      using result_type = typename std::result_of<F(std::declval<Args>()...)::type;
  #endif

最容易被忽略的坑：std::result_of 对 void 返回值的处理

它能推导出 void，但一旦你拿这个 type 去做 sizeof 或模板特化，就可能触发未定义行为 —— 因为某些老标准库实现里，std::result_of<...>::type</...> 对 void 场景没做充分约束。

真实使用场景中，这会导致：

• 用 std::result_of 推导后接 std::enable_if_t<std::is_same_v<R, void>>，结果 SFINAE 失效，编译器报硬错误而非静默丢弃
• 在 trait 检测中嵌套使用（比如判断某函数是否返回 void），应优先改用 std::is_void_v<std::invoke_result_t<F, Args...>>，更稳
• 如果必须用 std::result_of，记得加一层 std::decay_t 再判断：std::is_void_v<std::decay_t<typename std::result_of<...>::type>>

越老的代码越容易在这里卡住，因为没人想到 void 也会让类型推导变脆弱。