blocks|key|197468|text|std::enable_if在模板参数演绎过程中依赖于"“(又名SFINAE)原则。这是一个非常脆弱的语言特性，您需要非常小心才能正确使用它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|197469|197470|如果enable_if中的条件包含嵌套模板或类型定义(提示:查找::标记)，则这些嵌套模板或类型的解析通常是非推导上下文。这种非推导上下文上的任何替换失败都是error.|ordered-list-item|197471|the多个enable_if重载中的各种条件不能有任何重叠，因为重载解析将是不明确的。这是你作为作者需要检查自己的东西，尽管你会得到好的编译器warnings.|197472|enable_if在重载解析期间操纵一组可行的函数，这可能会有令人惊讶的交互，这取决于从其他作用域(例如，通过ADL)引入的其他函数的存在。这使得它不是很健壮。|197473|197474|简而言之，当它工作时，它可以工作，但当它不工作时，它可能很难调试。一种非常好的替代方法是使用标记分派，即委托给一个实现函数(通常在detail命名空间或帮助器类中)，该实现函数根据您在enable_if中使用的相同编译时条件接收伪参数。|197475|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+*/)+{}
}|code-block|syntax|javascript|197476|标签调度并不操作重载集，而是通过编译时表达式(例如，在类型特征中)提供适当的参数，帮助您准确地选择所需的函数。根据我的经验，这更容易调试和正确。如果您是一个具有复杂类型特征的有抱负的库编写者，那么您可能需要使用enable_if，但是对于大多数经常使用的编译时条件，不推荐使用它。|197477|entityMap^0|0|E|F|6|0|0|2|9|W|2|1I|6|27|5|0|5|9|0|0|9|0|0|1A|4|1T|6|2K|9|0|0|2X|9|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|15|8|@]|E|@]|F|$]]|$1|H|3|I|5|J|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|D]|$9|1D|A|1E|B|D]]|E|@]|F|$]]|$1|K|3|L|5|J|7|1F|8|@$9|1G|A|1H|B|C]]|E|@]|F|$]]|$1|M|3|N|5|J|7|1I|8|@$9|1J|A|1K|B|C]]|E|@]|F|$]]|$1|O|3|-4|5|6|7|1L|8|@]|E|@]|F|$]]|$1|P|3|Q|5|6|7|1M|8|@$9|1N|A|1O|B|D]|$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]]|E|@]|F|$]]|$1|R|3|S|5|T|7|1T|8|@]|E|@]|F|$U|V]]|$1|W|3|X|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|E|@]|F|$]]|$1|Y|3|-4|5|6|7|1X|8|@]|E|@]|F|$]]]|Z|$]]

<code>std::enable_if</code> relies on the "<a href="http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error">Substition Failure Is Not An Error</a>" (aka SFINAE) principle during template argument deduction. This is a very fragile language feature and you need to be very careful to get it right. 

<ol>
<li>if your condition inside the <code>enable_if</code> contains a nested template or type definition (hint: look for <code>::</code> tokens), then the resolution of these nested tempatles or types are usually a non-deduced context. Any substitution failure on such a non-deduced context is an error.</li>
<li>the various conditions in multiple <code>enable_if</code> overloads cannot have any overlap because overload resolution would be ambiguous. This is something that you as an author need to check yourself, although you'd get good compiler warnings.</li>
<li><code>enable_if</code> manipulates the set of viable functions during overload resolution which can have surprising interactions depending on the presence of other functions that are brought in from other scopes (e.g. through ADL). This makes it not very robust.</li>
</ol>

In short, when it works it works, but when it doesn't it can be very hard to debug. A very good alternative is to use tag dispatching, i.e. to delegate to an implementation function (usually in a <code>detail</code> namespace or in a helper class) that receives a dummy argument based on the same compile-time condition that you use in the <code>enable_if</code>.

<pre><code>template&lt;typename T&gt;
T fun(T arg) 
{ 
 return detail::fun(arg, typename some_template_trait&lt;T&gt;::type() ); 
}

namespace detail {
 template&lt;typename T&gt;
 fun(T arg, std::false_type /* dummy */) { }

 template&lt;typename T&gt;
 fun(T arg, std::true_type /* dummy */) {}
}
</code></pre>

Tag dispatching does not manipulate the overload set, but helps you select exactly the function you want by providing the proper arguments through a compile-time expression (e.g. in a type trait). In my experience, this is much easier to debug and get right. If you are an aspiring library writer of sophisticated type traits, you might need <code>enable_if</code> somehow, but for most regular use of compile-time conditions it's not recommended.

blocks|key|197492|text|将hack放在模板参数中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|197493|与其他方法相比，enable_if+on+template参数方法至少有两个优点：|offset|length|style|CODE|197494|197495|可读性:+enable_if的使用和返回/参数类型没有合并到一个混乱的typename消歧器和嵌套类型访问块中；即使消歧器和嵌套类型的混乱可以通过别名模板减轻，这仍然会将两个不相关的东西合并在一起。enable_if的使用与模板参数相关，而与返回类型无关。将它们放在模板参数中意味着它们更接近matters;|unordered-list-item|197496|universal的适用性:构造函数没有返回类型，一些运算符不能有额外的参数，所以其他两个选项都不能应用到所有地方。将enable_if放在模板参数中可以在任何地方使用，因为无论如何都只能在模板上使用SFINAE。|197497|197498|对我来说，可读性是这个选择的主要动机因素。|197499|entityMap^0|0|8|9|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|Y|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Put the hack in the template parameters.

The <code>enable_if</code> on template parameter approach has at least two advantages over the others:

<ul>
<li>readability: the enable_if use and the return/argument types are not merged together into one messy chunk of typename disambiguators and nested type accesses; even though the clutter of the disambiguator and nested type can be mitigated with alias templates, that would still merge two unrelated things together. The enable_if use is related to the template parameters not to the return types. Having them in the template parameters means they are closer to what matters;</li>
<li>universal applicability: constructors don't have return types, and some operators cannot have extra arguments, so neither of the other two options can be applied everywhere. Putting enable_if in a template parameter works everywhere since you can only use SFINAE on templates anyway.</li>
</ul>

For me, the readability aspect is the big motivating factor in this choice.

blocks|key|200357|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|200358|哪种解决方案应该是首选的，为什么我应该避免其他解决方案？|blockquote|200359|200360|200361|选项1:模板参数中的enable_if|offset|length|style|CODE|200362|200363|它在构造函数中可用。|unordered-list-item|200364|200365|200366|它在用户定义的转换运算符中可用。|200367|200368|200369|它需要C%2B%2B11或更高版本。|200370|200371|200372|在我看来，它更具可读性。|200373|200374|200375|很容易被误用并在重载时产生错误：|200376|200377|template::value>>+void+f()+{/*...*/}+template::value>>+void+f()+{/*...*/}+//重新定义:两者都只是template+f()|200378|请注意，使用了typename+=+std::enable_if_t<cond>而不是正确的std::enable_if_t<cond,+int>::type+=+0|200379|选项2:返回类型中的enable_if|200380|它不能与构造函数(没有返回类型)一起使用，也不能在用户定义的转换运算符中使用(因为它不是deducible)|200381|It+pre-C%2B%2B11.|200382|
|200383|Second+|200384|200385|可读性更好的IMO。|200386|200387|200388|选项3:函数参数中的enable_if|200389|在用户定义转换运算符中不能使用函数签名(它们没有pre-C%2B%2B11.|200390|It，不能在具有固定数量的参数的方法中使用，如一元/二元运算符|200391|200392|+%2B，-，*和其他。|200393|200394|它在继承中使用是安全的(参见below).|200395|200396|Changes+|200397|(你基本上有一个额外的作为最后一个参数的void*+=+nullptr)；这会导致指向函数的指针行为不同，等等。|200398|200399|200400|200401|成员函数模板和非成员函数模板有什么区别吗？|200402|200403|200404|继承和using之间有细微的区别|200405|根据using-declarator+(强调我的观点)：|200406|namespace.udecl|200407|200408|使用声明程序引入的声明集是通过对使用声明程序中的名称执行限定名称查找(basic.lookup.qual，class.member.lookup)来找到的，但不包括如下所述的隐藏函数。..。当使用声明符将声明从基类带入派生类时，派生类中的成员函数和成员函数模板覆盖和/或隐藏基类中具有相同名称、参数类型列表、cv限定和引用限定符(如果有)的成员函数和成员函数模板(而不是冲突)。这样的隐藏或被覆盖的声明被排除在使用声明器引入的声明集之外。|BOLD|200409|200410|200411|因此，对于模板参数和返回类型，方法都被隐藏在以下场景中：|200412|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()+{}
};|code-block|syntax|javascript|200413|Demo+(gcc找错了基函数)。|200414|然而，对于参数，类似的情况是可行的：|200415|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)+{}
};|200416|Demo|200417|entityMap|0|LINK|mutability|MUTABLE|url|http://www.eel.is/c%2B%2Bdraft/namespace.udecl#1|1|http://coliru.stacked-crooked.com/a/de74c012f6fcafd0|2|http://coliru.stacked-crooked.com/a/b5eb2084cca34b9b^0|0|0|0|0|A|9|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|7|X|1A|11|0|A|9|0|0|0|0|0|0|0|0|0|A|9|0|0|0|0|1|1|3|1|5|1|0|0|0|0|0|K|F|0|0|0|0|0|0|0|3|5|0|2|G|0|0|F|0|0|0|51|12|0|0|0|0|S|0|0|0|H|0|4|1|0|0|I|0|0|0|4|0|4|2|0^^$0|@$1|2|3|-4|4|5|6|3G|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|3H|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|3I|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|3J|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|3K|7|@$H|3L|I|3M|J|K]]|8|@]|9|$]]|$1|L|3|-4|4|5|6|3N|7|@]|8|@]|9|$]]|$1|M|3|N|4|O|6|3O|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|3P|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|3Q|7|@]|8|@]|9|$]]|$1|R|3|S|4|O|6|3R|7|@]|8|@]|9|$]]|$1|T|3|-4|4|5|6|3S|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|3T|7|@]|8|@]|9|$]]|$1|V|3|W|4|O|6|3U|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|3V|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|3W|7|@]|8|@]|9|$]]|$1|Z|3|10|4|O|6|3X|7|@]|8|@]|9|$]]|$1|11|3|-4|4|5|6|3Y|7|@]|8|@]|9|$]]|$1|12|3|-4|4|5|6|3Z|7|@]|8|@]|9|$]]|$1|13|3|14|4|O|6|40|7|@]|8|@]|9|$]]|$1|15|3|-4|4|5|6|41|7|@]|8|@]|9|$]]|$1|16|3|17|4|5|6|42|7|@]|8|@]|9|$]]|$1|18|3|19|4|5|6|43|7|@$H|44|I|45|J|K]|$H|46|I|47|J|K]]|8|@]|9|$]]|$1|1A|3|1B|4|5|6|48|7|@$H|49|I|4A|J|K]]|8|@]|9|$]]|$1|1C|3|1D|4|5|6|4B|7|@]|8|@]|9|$]]|$1|1E|3|1F|4|O|6|4C|7|@]|8|@]|9|$]]|$1|1G|3|1H|4|5|6|4D|7|@]|8|@]|9|$]]|$1|1I|3|1J|4|O|6|4E|7|@]|8|@]|9|$]]|$1|1K|3|-4|4|O|6|4F|7|@]|8|@]|9|$]]|$1|1L|3|1M|4|O|6|4G|7|@]|8|@]|9|$]]|$1|1N|3|-4|4|5|6|4H|7|@]|8|@]|9|$]]|$1|1O|3|-4|4|5|6|4I|7|@]|8|@]|9|$]]|$1|1P|3|1Q|4|5|6|4J|7|@$H|4K|I|4L|J|K]]|8|@]|9|$]]|$1|1R|3|1S|4|5|6|4M|7|@]|8|@]|9|$]]|$1|1T|3|1U|4|O|6|4N|7|@]|8|@]|9|$]]|$1|1V|3|1H|4|5|6|4O|7|@]|8|@]|9|$]]|$1|1W|3|1X|4|O|6|4P|7|@$H|4Q|I|4R|J|K]|$H|4S|I|4T|J|K]|$H|4U|I|4V|J|K]]|8|@]|9|$]]|$1|1Y|3|1H|4|5|6|4W|7|@]|8|@]|9|$]]|$1|1Z|3|20|4|O|6|4X|7|@]|8|@]|9|$]]|$1|21|3|1H|4|5|6|4Y|7|@]|8|@]|9|$]]|$1|22|3|23|4|O|6|4Z|7|@]|8|@]|9|$]]|$1|24|3|25|4|O|6|50|7|@$H|51|I|52|J|K]]|8|@]|9|$]]|$1|26|3|-4|4|5|6|53|7|@]|8|@]|9|$]]|$1|27|3|-4|4|5|6|54|7|@]|8|@]|9|$]]|$1|28|3|-4|4|5|6|55|7|@]|8|@]|9|$]]|$1|29|3|2A|4|C|6|56|7|@]|8|@]|9|$]]|$1|2B|3|-4|4|5|6|57|7|@]|8|@]|9|$]]|$1|2C|3|-4|4|5|6|58|7|@]|8|@]|9|$]]|$1|2D|3|2E|4|5|6|59|7|@$H|5A|I|5B|J|K]]|8|@]|9|$]]|$1|2F|3|2G|4|5|6|5C|7|@$H|5D|I|5E|J|K]]|8|@]|9|$]]|$1|2H|3|2I|4|5|6|5F|7|@]|8|@$H|5G|I|5H|1|5I]]|9|$]]|$1|2J|3|-4|4|5|6|5J|7|@]|8|@]|9|$]]|$1|2K|3|2L|4|C|6|5K|7|@$H|5L|I|5M|J|2M]]|8|@]|9|$]]|$1|2N|3|-4|4|5|6|5N|7|@]|8|@]|9|$]]|$1|2O|3|-4|4|5|6|5O|7|@]|8|@]|9|$]]|$1|2P|3|2Q|4|5|6|5P|7|@$H|5Q|I|5R|J|2M]]|8|@]|9|$]]|$1|2R|3|2S|4|2T|6|5S|7|@]|8|@]|9|$2U|2V]]|$1|2W|3|2X|4|5|6|5T|7|@$H|5U|I|5V|J|2M]]|8|@$H|5W|I|5X|1|5Y]]|9|$]]|$1|2Y|3|2Z|4|5|6|5Z|7|@$H|60|I|61|J|2M]]|8|@]|9|$]]|$1|30|3|31|4|2T|6|62|7|@]|8|@]|9|$2U|2V]]|$1|32|3|33|4|5|6|63|7|@$H|64|I|65|J|2M]]|8|@$H|66|I|67|1|68]]|9|$]]|$1|34|3|-4|4|5|6|69|7|@]|8|@]|9|$]]]|35|$36|$4|37|38|39|9|$3A|3B]]|3C|$4|37|38|39|9|$3A|3D]]|3E|$4|37|38|39|9|$3A|3F]]]]

<blockquote>
Which solution should be preferred and why should I avoid others?
</blockquote>
<h3>Option 1: <code>enable_if</code> in the template parameter</h3>
<ul>
<li>It is usable in Constructors.
</li>
<li>It is usable in user-defined conversion operator.
</li>
<li>It requires C++11 or later.
</li>
<li>In my opinion, it is the more readable.
</li>
<li>It is easy to misuse and produce errors with overloads:
<pre><code>template&lt;typename T, typename = std::enable_if_t&lt;std::is_same&lt;T, int&gt;::value&gt;&gt;
void f() {/*...*/}

template&lt;typename T, typename = std::enable_if_t&lt;std::is_same&lt;T, float&gt;::value&gt;&gt;
void f() {/*...*/} // Redefinition: both are just template&lt;typename, typename&gt; f()
</code></pre>
Notice the use of <code>typename = std::enable_if_t&lt;cond&gt;</code> instead of the correct <code>std::enable_if_t&lt;cond, int&gt;::type = 0</code>
</li>
</ul>
<h3>Option 2 : <code>enable_if</code> in the return type</h3>
<ul>
<li>It cannot be used with constructors (which have no return type)</li>
<li>It cannot be used in user-defined conversion operator (as it is not deducible)</li>
<li>It can be used pre-C++11.</li>
<li>Second more readable IMO.</li>
</ul>
<h3>Option 3: <code>enable_if</code> in a function parameter</h3>
<ul>
<li>It can be use pre-C++11.</li>
<li>It is usable in Constructors.</li>
<li>It cannot be used in user-defined conversion operators (they have no parameters)</li>
<li>It cannot be used in methods with a fixed number of arguments, such as unary/binary operators <code>+</code>, <code>-</code>, <code>*</code> and others.</li>
<li>It is safe for use in inheritance (see below).</li>
<li>Changes function signature (you have basically an extra as last argument <code>void* = nullptr</code>); this causes pointers pointers to the function to behave differently and so on.</li>
</ul>
<blockquote>
Are there any differences for member and non-member function templates?
</blockquote>
There are subtle differences with inheritance and <code>using</code>:
According to the <code>using-declarator</code> (emphasis mine):
<a href="http://www.eel.is/c++draft/namespace.udecl#1" rel="nofollow noreferrer">namespace.udecl</a>
<blockquote>
The set of declarations introduced by the using-declarator is found by performing qualified name lookup ([basic.lookup.qual], [class.member.lookup]) for the name in the using-declarator, excluding functions that are hidden as described below.
</blockquote>
<blockquote>
...
</blockquote>
<blockquote>
When a using-declarator brings declarations from a base class into a derived class, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list, cv-qualification, and ref-qualifier (if any) in a base class (rather than conflicting). Such hidden or overridden declarations are excluded from the set of declarations introduced by the using-declarator.
</blockquote>
So for both template argument and return type, methods are hidden is following scenario:
<pre><code>struct Base
{
 template &lt;std::size_t I, std::enable_if_t&lt;I == 0&gt;* = nullptr&gt;
 void f() {}

 template &lt;std::size_t I&gt;
 std::enable_if_t&lt;I == 0&gt; g() {}
};

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

 template &lt;std::size_t I&gt;
 std::enable_if_t&lt;I == 1&gt; g() {}
};
</code></pre>
<a href="http://coliru.stacked-crooked.com/a/de74c012f6fcafd0" rel="nofollow noreferrer">Demo</a> (gcc wrongly finds the base function).
Whereas with argument, similar scenario works:
<pre><code>struct Base
{
 template &lt;std::size_t I&gt;
 void h(std::enable_if_t&lt;I == 0&gt;* = nullptr) {}
};

struct S : Base
{
 using Base::h; // Base::h&lt;0&gt; is visible
 
 template &lt;std::size_t I&gt;
 void h(std::enable_if_t&lt;I == 1&gt;* = nullptr) {}
};
</code></pre>
<a href="http://coliru.stacked-crooked.com/a/b5eb2084cca34b9b" rel="nofollow noreferrer">Demo</a>

blocks|key|200432|text|“哪种解决方案应该是首选的，为什么我应该避免其他解决方案？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|200433|当这个问题被问到时，来自<type_traits>的std::enable_if是最好的工具，其他的答案也是合理的，直到C%2B%2B17。|offset|length|style|CODE|200434|如今，在C%2B%2B20中，我们可以通过requires直接支持编译器。|200435|#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;+}+++
};|code-block|syntax|javascript|200436|entityMap^0|0|C|D|Q|E|0|H|8|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]|$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|P|$]]

&quot;Which solution should be preferred and why should I avoid others?&quot;
When the question was asked, <code>std::enable_if</code> from <code>&lt;type_traits&gt;</code> was the best tool available, and the other answers are reasonable up to C++17.
Nowadays in C++20 we have direct compiler support via <code>requires</code>.
<pre><code>#include &lt;concepts
template&lt;typename T&gt;
struct Check20
{
 template&lt;typename U = T&gt;
 U read() requires std::same_as &lt;U, int&gt;
 { return 42; }
 
 template&lt;typename U = T&gt;
 U read() requires std::same_as &lt;U, double&gt;
 { return 3.14; } 
};
</code></pre>

Scott Meyers posted <a href="http://scottmeyers.blogspot.de/2013/01/effective-c11-content-and-status.html" rel="noreferrer">content and status</a> of his next book EC++11.
He wrote that one item in the book could be "Avoid <code>std::enable_if</code> in function signatures".

<code>std::enable_if</code> can be used as a function argument, as a return type or as a class template or function template parameter to conditionally remove functions or classes from overload resolution.

In <a href="https://stackoverflow.com/questions/11055923/stdenable-if-parameter-vs-template-parameter">this question</a> all three solution are shown.

As function parameter:

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

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

As template parameter:

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

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

As return type:

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

 template&lt;typename U = T&gt;
 typename std::enable_if&lt;std::is_same&lt;U, double&gt;::value, U&gt;::type read() {
 return 3.14;
 } 
};
</code></pre>

<ul>
<li>Which solution should be preferred and why should I avoid others? </li>
<li>In which cases "Avoid <code>std::enable_if</code> in function signatures" concerns usage as return type (which is not part of normal function signature but of template specializations)?</li>
<li>Are there any differences for member and non-member function templates?</li>
</ul>

Why should I avoid std::enable_if in function signatures

编译器

Scott Meyer发布了他的下一本书EC++11的，他在书中写道，书中的一条可能是“在函数签名中避免std::enable_if”。std::enable_if可以用作函数参数、返回类型或类模板或函数模板参数，以便有条件地从重载解析中删除函数或类。在中，显示了所有三种解决方案。作为函数参数：template<typ...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我应该在函数签名中避免使用std::enable_ifEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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