为什么使用 std::forward<T> 而不是 static_cast<T&&>

Question

当给出以下结构的代码时

template <typename... Args>
void foo(Args&&... args) { ... }

我经常看到库代码在函数中使用static_cast<Args&&> 进行参数转发。通常，这样做的理由是使用static_cast 可以避免不必要的模板实例化。

给定语言的引用折叠和模板推导规则。我们通过static_cast<Args&&> 获得了完美的转发，此声明的证据如下（在误差范围内，我希望答案能启发）

• 当给定右值引用时（或为了完整性 - 没有像this example 中的引用限定），这会以结果为右值的方式折叠引用。使用的规则是&& && -> &&（上面的规则1）
• 当给定左值引用时，这会折叠引用以使结果是左值。这里使用的规则是& && -> &（上面的规则2）

这实质上是让foo() 将参数转发到上面示例中的bar()。这也是您在此处使用std::forward<Args> 时会得到的行为。

---

问题 - 为什么在这些情况下使用 std::forward？避免额外的实例化是否有理由打破约定？

Howard Hinnant 的论文 n2951 指定了 6 个约束条件，std::forward 的任何实现都应该“正确”地运行。这些是

1. 应该将左值作为左值转发
2. 应该将右值作为右值转发
3. 不应将右值作为左值转发
4. 应将较少的 cv 限定表达式转发到更多 cv 限定的表达式
5. 应将派生类型的表达式转发到可访问、明确的基类型
6. 不应转发任意类型转换

(1) 和 (2) 被证明可以与上面的 static_cast<Args&&> 一起正常工作。 (3) - (6) 在这里不适用，因为在推导的上下文中调用函数时，这些都不会发生。

---

注意：我个人更喜欢使用std::forward，但我的理由纯粹是我更喜欢遵守约定。

Answer 1

Scott Meyers 说std::forward 和std::move 主要是为了方便。他甚至表示std::forward 可用于执行std::forward 和std::move 的功能。
《Effective Modern C++》的部分节选：

第 23 项：了解 std::move 和 std::forward
...
std::forward 的故事与 std::move 的故事相似，但 std::move 无条件地将其参数转换为 rvalue，std::forward 仅在某些条件下才会这样做。 std::forward 是一个条件转换。仅当其参数使用 rvalue 初始化时，它才会强制转换为 rvalue。
...
鉴于std::move 和std::forward 都归结为强制转换，唯一的区别是std::move 总是强制转换，而std::forward 只是有时会，你可能会问我们是否可以省去std::move 而只是在任何地方使用std::forward。从纯粹的技术角度来看，答案是肯定的：std::forward 可以做到这一切。 std::move 不是必需的。 当然，这两个函数都不是必需的，因为我们可以在任何地方编写强制转换，但我希望我们同意那会很糟糕。
...
std::move 的吸引力在于方便、减少出错的可能性和更清晰...

对于那些感兴趣的人，比较assembly 中的std::forward<T> 与static_cast<T&&>（未进行任何优化）在使用lvalue 和rvalue 调用时。

Answer 2

forward 表达了意图，使用起来可能比static_cast 更安全：static_cast 考虑转换，但使用forward 检测到一些危险且可能是非故意的转换：

struct A{
   A(int);
   };

template<class Arg1,class Arg2>
Arg1&& f(Arg1&& a1,Arg2&& a2){
   return static_cast<Arg1&&>(a2); //  typing error: a1=>a2
   }

template<class Arg1,class Arg2>
Arg1&& g(Arg1&& a1,Arg2&& a2){
   return forward<Arg1>(a2); //  typing error: a1=>a2
   }

void test(const A a,int i){
   const A& x = f(a,i);//dangling reference
   const A& y = g(a,i);//compilation error
  }

_{错误信息示例：compiler explorer link}

---

如何应用这个理由：通常，这样做的理由是使用 static_cast 避免了不必要的模板实例化。

编译时间比代码可维护性更成问题吗？编码员是否应该浪费时间考虑在代码中的每一行最小化“不必要的模板实例化”？

当一个模板被实例化时，它的实例化会导致模板的实例化，在它的定义和声明中使用。因此，例如，如果您有以下功能：

  template<class T> void foo(T i){
     foo_1(i),foo_2(i),foo_3(i);
     }

其中foo_1,foo_2,foo_3是模板，foo的实例化会导致3个实例化。然后递归地如果这些函数导致其他 3 个模板函数的实例化，例如，您可以获得 3*3=9 实例化。因此，您可以将这个实例化链视为一棵树，其中根函数实例化可以导致数千个实例化为指数增长的连锁反应。另一方面，像forward 这样的函数是这个实例化树中的一个叶子。所以避免它的实例化可能只能避免1个实例化。

因此，避免模板实例化爆炸的最佳方法是对“根”类和“根”函数的参数类型使用动态多态性，然后仅对在此实例化树中实际上处于较高位置的时间关键函数使用静态多态性.

因此，在我看来，使用static_cast 代替forward 来避免实例化与使用更具表现力（和更安全）代码的好处相比是浪费时间。在代码架构级别更有效地管理模板实例化爆炸。

Answer 3

这是我的 2.5，不是那么技术性的美分：今天 std::forward 确实只是一个普通的旧 static_cast<T&&> 并不意味着明天它也会以完全相同的方式实现。我认为委员会需要一些东西来反映std::forward 今天所实现的期望行为，因此，不会在任何地方转发任何东西的forward 应运而生。

在std::forward 的保护伞下正式确定所需的行为和期望，从理论上讲，没有人会阻止未来的实施者提供std::forward，而不是static_cast<T&&>，而是他自己的特定实施，而实际上没有采取考虑到static_cast<T&&>，因为唯一重要的是std::forward 的正确用法和行为。