Dlaczego należy unikać std :: enable_if w sygnaturach funkcji
Scott Meyers napisałtreść i status jego następnej książki EC ++ 11. Napisał, że jednym z elementów książki może być"Uniknąćstd::enable_if
w podpisach funkcji ”.
std::enable_if
może być używany jako argument funkcji, jako typ powrotu lub jako szablon klasy lub parametr szablonu funkcji, aby warunkowo usunąć funkcje lub klasy z rozdzielczości przeciążenia.
Wto pytanie pokazane są wszystkie trzy rozwiązania.
Jako parametr funkcji:
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; }
};
Jako parametr szablonu:
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; }
};
Jako typ zwrotu:
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;
}
};
Które rozwiązanie powinno być preferowane i dlaczego powinienem unikać innych?W jakich przypadkach"Uniknąćstd::enable_if
w podpisach funkcji ” dotyczy użycia jako typu powrotu (który nie jest częścią normalnego podpisu funkcji, ale specjalizacji szablonów)?Czy są jakieś różnice w szablonach funkcji członków i innych członków?