7
Więcej niż jeden raz (nawet na SO) Widziałem kodu:Czy sprawdzane pakiety parametrów ochronnych są przyczyną źle sformułowanych programów?
template<typename U, typename... G, typename T = Traits<U>>
struct {
static_assert(sizeof...(G) == 0, "!");
// ...
};
Albo to:
template<typename T, typename... G, typename = std::enable_if_t<condition<T>>
void func(T &&t) {
static_assert(sizeof...(G) == 0, "!");
// ....
}
Zamiarem było uniknięcie użytkowników złamać reguły gry robiąc coś w następujący sposób:
template<typename T, typename = std::enable_if_t<std::is_same<T, int>>
void func(T &&t) {
// ....
}
// ...
func<int&, void>(my_int);
Z pakietem parametrów strażnika nie można zastąpić wartości domyślnej.
Po drugiej stronie, sprawdzanie rozmiaru zapobiega zanieczyszczaniu specjalizacji nieprzydatnymi parametrami.
W każdym razie, z powodu [temp.res/8] mamy, że:
Program jest źle sformułowane, nie diagnostyczny wymagane, jeśli:
[...]
- każda ważna specjalność o zmiennej liczbie argumentów szablonu wymaga pustego szablonu parametr pakiet lub
[...]
Dlatego są programy, które zawierają powyższe fragmenty źle sformułowane, czy nie?
Tak. Z tego powodu doświadczeni TMP'lery używali szablonu klasy, który pobiera zarówno rozmiar pakietu, jak i 'T', aby określić warunek' static_assert'. (Chociaż nie wiem, czy doświadczeni TMP'erzy rzeczywiście zastosowaliby to podejście.) – Columbo
Nie widzę sensu w używaniu pakietu parametrów, po prostu można użyć 'szablonu, int> = 0>, których nie można obejść przez użytkownika i które mogą być również użyte w SFINAE. –
Corristo
@Corristo, nigdy nie wydawaj się takim kodem. Dobra sztuczka! – paulotorrens