为什么我应该在函数签名中避免 std::enable_if

Question

Scott Meyers 发布了他的下一本书 EC++11 的 content and status。 他写道，书中的一项内容可能是“在函数签名中避免std::enable_if”。

std::enable_if 可用作函数参数、返回类型或类模板或函数模板参数，以有条件地从重载决议中删除函数或类。

在this question 中显示了所有三个解决方案。

作为函数参数：

template<typename T>
struct Check1
{
   template<typename U = T>
   U read(typename std::enable_if<
          std::is_same<U, int>::value >::type* = 0) { return 42; }

   template<typename U = T>
   U read(typename std::enable_if<
          std::is_same<U, double>::value >::type* = 0) { return 3.14; }   
};

作为模板参数：

template<typename T>
struct Check2
{
   template<typename U = T, typename std::enable_if<
            std::is_same<U, int>::value, int>::type = 0>
   U read() { return 42; }

   template<typename U = T, typename std::enable_if<
            std::is_same<U, double>::value, int>::type = 0>
   U read() { return 3.14; }   
};

作为返回类型：

template<typename T>
struct Check3
{
   template<typename U = T>
   typename std::enable_if<std::is_same<U, int>::value, U>::type read() {
      return 42;
   }

   template<typename U = T>
   typename std::enable_if<std::is_same<U, double>::value, U>::type read() {
      return 3.14;
   }   
};

• 应该首选哪种解决方案，为什么要避免使用其他解决方案？
• 在哪些情况下“在函数签名中避免 std::enable_if” 涉及用作返回类型（它不是普通函数签名的一部分，而是模板特化的一部分）？
• 成员函数模板和非成员函数模板有什么区别吗？

Answer 1

将 hack 放入模板参数中。

模板参数方法上的enable_if 与其他方法相比至少有两个优点：

• 可读性：enable_if 使用和返回/参数类型没有合并到一个杂乱的类型名消歧器和嵌套类型访问块中；即使可以使用别名模板来减轻消歧器和嵌套类型的混乱，但这仍然会将两个不相关的东西合并在一起。 enable_if 的使用与模板参数有关，与返回类型无关。将它们包含在模板参数中意味着它们更接近重要的内容；

• 普遍适用：构造函数没有返回类型，并且某些运算符不能有额外的参数，因此其他两个选项都不能在任何地方应用。将 enable_if 放在模板参数中适用于任何地方，因为无论如何您只能在模板上使用 SFINAE。

对我来说，可读性方面是这个选择的最大动力。

Answer 2

std::enable_if 在模板参数推导期间依赖于“Substition Failure Is Not An Error”（又名 SFINAE）原则。这是一个非常脆弱的语言功能，您需要非常小心才能正确使用它。

1. 如果enable_if 中的条件包含嵌套模板或类型定义（提示：查找:: 标记），那么这些嵌套模板或类型的解析通常是非推断上下文强>。在这种非推断上下文中的任何替换失败都是错误。
2. 多个enable_if 重载中的各种条件不能有任何重叠，因为重载解析会不明确。这是您作为作者需要自己检查的事情，尽管您会收到很好的编译器警告。
3. enable_if 在重载解析期间操纵一组可行的函数，这可能会产生令人惊讶的交互，这取决于从其他范围（例如通过 ADL）引入的其他函数的存在。这使得它不是很健壮。

简而言之，当它工作时，它工作，但当它不工作时，它可能很难调试。一个很好的替代方法是使用标签调度，即委托给一个实现函数（通常在detail 命名空间或助手类中），该函数接收基于相同编译时间的虚拟参数您在enable_if 中使用的条件。

template<typename T>
T fun(T arg) 
{ 
    return detail::fun(arg, typename some_template_trait<T>::type() ); 
}

namespace detail {
    template<typename T>
    fun(T arg, std::false_type /* dummy */) { }

    template<typename T>
    fun(T arg, std::true_type /* dummy */) {}
}

标签调度不会操纵重载集，而是通过编译时表达式（例如，在类型特征中）提供正确的参数来帮助您准确选择所需的函数。以我的经验，这更容易调试和正确。如果你是一个有抱负的复杂类型特征的库作者，你可能需要enable_if，但对于大多数常规使用的编译时条件，不建议这样做。

Answer 3

应该首选哪种解决方案，为什么要避免使用其他解决方案？

选项1：模板参数中的enable_if

• 在构造函数中可用。

• 可用于自定义转换运算符。

• 它需要 C++11 或更高版本。

• 在我看来，它更具可读性。

• 重载容易误用和产生错误：

  template<typename T, typename = std::enable_if_t<std::is_same<T, int>::value>>
  void f() {/*...*/}
  
  template<typename T, typename = std::enable_if_t<std::is_same<T, float>::value>>
  void f() {/*...*/} // Redefinition: both are just template<typename, typename> f()
  

  注意使用typename = std::enable_if_t<cond> 而不是正确的std::enable_if_t<cond, int>::type = 0

选项 2：enable_if 在返回类型中

• 它不能与构造函数（没有返回类型）一起使用
• 不能用于用户定义的转换运算符（因为它不可推导）
• 可以在 C++11 之前使用。
• 第二个更易读的 IMO。

选项 3：enable_if 在函数参数中

• 可以使用 pre-C++11。
• 它可用于构造函数。
• 它不能用于用户定义的转换运算符（它们没有参数）
• 它不能用于具有固定数量参数的方法中，例如一元/二元运算符+、-、* 等。
• 在继承中使用它是安全的（见下文）。
• 改变函数签名（你基本上有一个额外的作为最后一个参数void* = nullptr）；这会导致指针指向函数的行为不同等等。

成员函数模板和非成员函数模板有什么区别吗？

继承和using有细微差别：

根据using-declarator（强调我的）：

namespace.udecl

通过对 using-declarator 中的名称执行限定名称查找 ([basic.lookup.qual], [class.member.lookup]) 来找到 using-declarator 引入的声明集，不包括以下函数如下所述隐藏。

...

当 using-declarator 将基类中的声明引入派生类时，派生类中的成员函数和成员函数模板会覆盖和/或隐藏同名的成员函数和成员函数模板，参数-基类中的类型列表、cv 限定符和 ref 限定符（如果有）（而不是冲突）。此类隐藏或覆盖的声明被排除在 using-declarator 引入的声明集中。

所以对于模板参数和返回类型，方法被隐藏如下场景：

struct Base
{
    template <std::size_t I, std::enable_if_t<I == 0>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 0> g() {}
};

struct S : Base
{
    using Base::f; // Useless, f<0> is still hidden
    using Base::g; // Useless, g<0> is still hidden
    
    template <std::size_t I, std::enable_if_t<I == 1>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 1> g() {}
};

Demo（gcc 错误地找到了基函数）。

虽然有参数，但类似的情况也有效：

struct Base
{
    template <std::size_t I>
    void h(std::enable_if_t<I == 0>* = nullptr) {}
};

struct S : Base
{
    using Base::h; // Base::h<0> is visible
    
    template <std::size_t I>
    void h(std::enable_if_t<I == 1>* = nullptr) {}
};

Demo

Answer 4

“应该首选哪种解决方案，为什么要避免使用其他解决方案？”

当问题被问到时，<type_traits> 中的std::enable_if 是可用的最佳工具，其他答案在 C++17 之前都是合理的。

现在在 C++20 中，我们通过 requires 直接支持编译器。

#include <concepts
template<typename T>
struct Check20
{
   template<typename U = T>
   U read() requires std::same_as <U, int>
   { return 42; }
   
   template<typename U = T>
   U read() requires std::same_as <U, double>
   { return 3.14; }   
};