这个可变参数模板代码有什么作用?

The code has no ordering guarantees, and if the return value of f for a given Arg has an overloaded operator, it can have unfortunate side effects.

有一些空白:

[](...){}(
  (
    f(std::forward<Args>(args)), 0
  )...
);

我们将从内部开始.

f(std::forward(args)) 是一个不完整的语句，可以用 ... 展开.展开时，它将在 args 之一上调用 f.调用此语句 INVOKE_F.

f(std::forward<Args>(args)) is an incomplete statement that can be expanded with a .... It will invoke f on one of args when expanded. Call this statement INVOKE_F.

(INVOKE_F, 0) 取f(args) 的返回值，应用operator, 然后0>.如果返回值没有覆盖，则丢弃 f(args) 的返回值并返回 0.调用此 INVOKE_F_0.如果 f 返回一个带有覆盖 operator,(int) 的类型，这里就会发生不好的事情，如果该运算符返回一个非 POD 类型的类型，你可以得到有条件地支持"行为稍后.

(INVOKE_F, 0) takes the return value of f(args), applies operator, then 0. If the return value has no overrides, this discards the return value of f(args) and returns a 0. Call this INVOKE_F_0. If f returns a type with an overriden operator,(int), bad things happen here, and if that operator returns a non-POD-esque type, you can get "conditionally supported" behavior later on.

[](...){} 创建一个将 C 风格的可变参数作为其唯一参数的 lambda.这与 C++11 参数包或 C++14 可变参数 lambda 不同.将非 POD 类型的类型传递给 ... 函数可能是非法的.调用这个HELPER

[](...){} creates a lambda that takes C-style variadics as its only argument. This isn't the same as C++11 parameter packs, or C++14 variadic lambdas. It is possibly illegal to pass non-POD-esque types to a ... function. Call this HELPER

HELPER(INVOKE_F_0...) 是一个参数包扩展.在调用 HELPER 的 operator() 的上下文中，这是一个合法的上下文.参数的评估未指定，并且由于 HELPER INVOKE_F_0... 的签名可能应该只包含普通的旧数据(在 C++03 中)，或者更多特别是 [expr.call]/p7 说:(通过@TC)

HELPER(INVOKE_F_0...) is a parameter pack expansion. in the context of invoking HELPER's operator(), which is a legal context. The evaluation of arguments is unspecified, and due to the signature of HELPER INVOKE_F_0... probably should only contain plain old data (in C++03 parlance), or more specifically [expr.call]/p7 says: (via @T.C)

传递具有非平凡复制构造函数、非平凡移动构造函数或非平凡析构函数的类类型(第 9 条)的潜在评估参数，没有相应的参数，有条件地支持实现定义的语义.

Passing a potentially-evaluated argument of class type (Clause 9) having a nontrivial copy constructor, a non-trivial move constructor, or a non-trivial destructor, with no corresponding parameter, is conditionally-supported with implementation-defined semantics.

所以这段代码的问题是顺序未指定并且它依赖于行为良好的类型或特定的编译器实现选择.

So the problems of this code is that the order is unspecified and it relies on well behaved types or specific compiler implementation choices.

我们可以修复operator,问题如下:

We can fix the operator, problem as follows:

template <class F, class... Args> 
void for_each_argument(F f, Args&&... args) { 
  [](...){}((void(f(std::forward<Args>(args))), 0)...); 
}

然后我们可以通过在初始化器中扩展来保证顺序:

then we can guarantee order by expanding in an initializer:

template <class F, class... Args> 
void for_each_argument(F f, Args&&... args) { 
  int unused[] = {(void(f(std::forward<Args>(args))), 0)...}; 
  void(unused); // suppresses warnings
}

但是当 Args... 为空时，上面会失败，所以添加另一个 0:

but the above fails when Args... is empty, so add another 0:

template <class F, class... Args> 
void for_each_argument(F f, Args&&... args) { 
  int unused[] = {0, (void(f(std::forward<Args>(args))), 0)...}; 
  void(unused); // suppresses warnings
}