C++
SFINAE (Errore di sostituzione non è un errore)

enable_if

std::enable_if è una comoda utilità per utilizzare le condizioni booleane per attivare SFINAE. È definito come:

template <bool Cond, typename Result=void>
struct enable_if { };

template <typename Result>
struct enable_if<true, Result> {
    using type = Result;
};

Cioè, enable_if<true, R>::type è un alias per R , mentre enable_if<false, T>::type è mal formato poiché quella specializzazione di enable_if non ha un type membro di tipo.

std::enable_if può essere usato per vincolare i template:

int negate(int i) { return -i; }

template <class F>
auto negate(F f) { return -f(); }

Qui, una chiamata a negate(1) fallirebbe a causa dell'ambiguità. Ma il secondo sovraccarico non è destinato a essere utilizzato per i tipi interi, quindi possiamo aggiungere:

int negate(int i) { return -i; }

template <class F, class = typename std::enable_if<!std::is_arithmetic<F>::value>::type>
auto negate(F f) { return -f(); }

Ora, l'istanziazione di negate<int> comporterebbe un errore di sostituzione poiché !std::is_arithmetic<int>::value è false . A causa di SFINAE, questo non è un errore grave, questo candidato viene semplicemente rimosso dal set di sovraccarico. Di conseguenza, negate(1) ha un solo candidato valido, che viene poi chiamato.

Quando usarlo

Vale la pena ricordare che std::enable_if è un aiuto su SFINAE, ma non è ciò che fa funzionare SFINAE in primo luogo. Consideriamo queste due alternative per implementare funzionalità simili a std::size , ovvero una size(arg) set di overload size(arg) che produce la dimensione di un contenitore o array:

// for containers
template<typename Cont>
auto size1(Cont const& cont) -> decltype( cont.size() );

// for arrays
template<typename Elt, std::size_t Size>
std::size_t size1(Elt const(&arr)[Size]);

// implementation omitted
template<typename Cont>
struct is_sizeable;

// for containers
template<typename Cont, std::enable_if_t<std::is_sizeable<Cont>::value, int> = 0>
auto size2(Cont const& cont);

// for arrays
template<typename Elt, std::size_t Size>
std::size_t size2(Elt const(&arr)[Size]);

Supponendo che is_sizeable sia scritto appropriatamente, queste due dichiarazioni dovrebbero essere esattamente equivalenti rispetto a SFINAE. Qual è il modo più semplice per scrivere, e quale è il modo più semplice da rivedere e capire a colpo d'occhio?

Consideriamo ora come potremmo voler implementare help aritmetici che evitino l'overflow dei caratteri interi in favore di un comportamento wrap-around o modulare. Il che incr(i, 3) ad es. incr(i, 3) sarebbe lo stesso di i += 3 salvo il fatto che il risultato sarebbe sempre definito anche se i sono un int con valore INT_MAX . Queste sono due alternative possibili:

// handle signed types
template<typename Int>
auto incr1(Int& target, Int amount)
-> std::void_t<int[static_cast<Int>(-1) < static_cast<Int>(0)]>;

// handle unsigned types by just doing target += amount
// since unsigned arithmetic already behaves as intended
template<typename Int>
auto incr1(Int& target, Int amount)
-> std::void_t<int[static_cast<Int>(0) < static_cast<Int>(-1)]>;
 
template<typename Int, std::enable_if_t<std::is_signed<Int>::value, int> = 0>
void incr2(Int& target, Int amount);
 
template<typename Int, std::enable_if_t<std::is_unsigned<Int>::value, int> = 0>
void incr2(Int& target, Int amount);

Ancora una volta qual è il modo più semplice per scrivere, e quale è il modo più semplice da rivedere e capire a colpo d'occhio?

Un punto di forza di std::enable_if è il modo in cui gioca con il refactoring e la progettazione dell'API. Se is_sizeable<Cont>::value è pensato per riflettere se cont.size() è valido, basta usare l'espressione così come appare per size1 può essere più conciso, anche se ciò potrebbe dipendere dal fatto che is_sizeable possa essere usato in più posti o meno . Contrasto a quello con std::is_signed che riflette la sua intenzione molto più chiaramente di quando la sua implementazione incr1 nella dichiarazione di incr1 .

void_t

template <class...> using void_t = void;

template <class...>
struct make_void { using type = void; };

template <typename... T>
using void_t = typename make_void<T...>::type;

template <class T, class=void>
struct has_foo : std::false_type {};

template <class T>
struct has_foo<T, void_t<decltype(std::declval<T&>().foo())>> : std::true_type {};

template<class T, class=void>
struct can_reference : std::false_type {};

template<class T>
struct can_reference<T, std::void_t<T&>> : std::true_type {};

struct details {
  template<template<class...>class Z, class=void, class...Ts>
  struct can_apply:
    std::false_type
  {};
  template<template<class...>class Z, class...Ts>
  struct can_apply<Z, std::void_t<Z<Ts...>>, Ts...>:
    std::true_type
  {};
};

template<template<class...>class Z, class...Ts>
using can_apply = details::can_apply<Z, void, Ts...>;

template<class T>
using ref_t = T&;

template<class T>
using can_reference = can_apply<ref_t, T>;    // Is T& well formed for T?

template<class T>
using dot_foo_r = decltype(std::declval<T&>().foo());

template<class T>
using can_dot_foo = can_apply< dot_foo_r, T >;    // Is T.foo() well formed for T?

finale decltype nei modelli di funzione

namespace details {
   using std::to_string;

   // this one is constrained on being able to call to_string(T)
   template <class T>
   auto convert_to_string(T const& val, int )
       -> decltype(to_string(val))
   {
       return to_string(val);
   }

   // this one is unconstrained, but less preferred due to the ellipsis argument
   template <class T>
   std::string convert_to_string(T const& val, ... )
   {
       std::ostringstream oss;
       oss << val;
       return oss.str();
   }
}

template <class T>
std::string convert_to_string(T const& val)
{
    return details::convert_to_string(val, 0);
}

Cos'è SFINAE

SFINAE sta per S ubstitution F ailure I s N OT A n e rror. Il codice malformato che deriva dal sostituire i tipi (o i valori) per creare un'istanza di un modello di funzione o un modello di classe non è un errore di compilazione difficile, viene considerato solo come un errore di deduzione.

I fallimenti di detrazioni su modelli di istanze di istanza o specializzazioni di modelli di classe rimuovono quel candidato dall'insieme di considerazioni - come se quel candidato fallito non esistesse per cominciare.

template <class T>
auto begin(T& c) -> decltype(c.begin()) { return c.begin(); }

template <class T, size_t N>
T* begin(T (&arr)[N]) { return arr; }

int vals[10];
begin(vals); // OK. The first function template substitution fails because
             // vals.begin() is ill-formed. This is not an error! That function
             // is just removed from consideration as a viable overload candidate,
             // leaving us with the array overload. 

Solo i guasti di sostituzione nel contesto immediato sono considerati errori di deduzione, tutti gli altri sono considerati errori gravi.

template <class T>
void add_one(T& val) { val += 1; }

int i = 4;
add_one(i); // ok

std::string msg = "Hello";
add_one(msg); // error. msg += 1 is ill-formed for std::string, but this
              // failure is NOT in the immediate context of substituting T

enable_if_all / enable_if_any

template<typename ...Args> void func(Args &&...args) { //... };

/// C++17: SFINAE constraints on all of the parameters in Args.
template<typename ...Args,
         std::enable_if_t<std::conjunction_v<custom_conditions_v<Args>...>>* = nullptr>
void func(Args &&...args) { //... };

/// C++17: SFINAE constraints on any of the parameters in Args.
template<typename ...Args,
         std::enable_if_t<std::disjunction_v<custom_conditions_v<Args>...>>* = nullptr>
void func(Args &&...args) { //... };

/// Helper for prior to C++14.
template<bool B, class T, class F >
using conditional_t = typename std::conditional<B,T,F>::type;

/// Emulate C++17 std::conjunction.
template<bool...> struct seq_or: std::false_type {};
template<bool...> struct seq_and: std::true_type {};

template<bool B1, bool... Bs>
struct seq_or<B1,Bs...>: 
  conditional_t<B1,std::true_type,seq_or<Bs...>> {};

template<bool B1, bool... Bs>
struct seq_and<B1,Bs...>:
  conditional_t<B1,seq_and<Bs...>,std::false_type> {};  

template<bool... Bs>
using enable_if_any = std::enable_if<seq_or<Bs...>::value>;

template<bool... Bs>
using enable_if_all = std::enable_if<seq_and<Bs...>::value>;

template<bool... Bs>
using enable_if_any_t = typename enable_if_any<Bs...>::type;

template<bool... Bs>
using enable_if_all_t = typename enable_if_all<Bs...>::type;

    /// SFINAE constraints on all of the parameters in Args.
    template<typename ...Args,
             enable_if_all_t<custom_conditions_v<Args>...>* = nullptr>
    void func(Args &&...args) { //... };

    /// SFINAE constraints on any of the parameters in Args.
    template<typename ...Args,
             enable_if_any_t<custom_conditions_v<Args>...>* = nullptr>
    void func(Args &&...args) { //... };

is_detected

Per generalizzare la creazione di type_trait: basato su SFINAE ci sono tratti sperimentali detected_or , detected_t , is_detected .

Con i parametri del template typename Default , template <typename...> Op e typename ... Args :

• is_detected : alias di std::true_type o std::false_type seconda della validità di Op<Args...>
• detected_t : alias di Op<Args...> o nonesuch seconda della validità di Op<Args...> .
• detected_or : alias di una struct con value_t che è is_detected e type che è Op<Args...> o Default dipendente dalla validità di Op<Args...>

che può essere implementato usando std::void_t per SFINAE come segue:

namespace detail {
    template <class Default, class AlwaysVoid,
              template<class...> class Op, class... Args>
    struct detector
    {
        using value_t = std::false_type;
        using type = Default;
    };

    template <class Default, template<class...> class Op, class... Args>
    struct detector<Default, std::void_t<Op<Args...>>, Op, Args...>
    {
        using value_t = std::true_type;
        using type = Op<Args...>;
    };

} // namespace detail

// special type to indicate detection failure
struct nonesuch {
    nonesuch() = delete;
    ~nonesuch() = delete;
    nonesuch(nonesuch const&) = delete;
    void operator=(nonesuch const&) = delete;
};

template <template<class...> class Op, class... Args>
using is_detected =
    typename detail::detector<nonesuch, void, Op, Args...>::value_t;

template <template<class...> class Op, class... Args>
using detected_t = typename detail::detector<nonesuch, void, Op, Args...>::type;

template <class Default, template<class...> class Op, class... Args>
using detected_or = detail::detector<Default, void, Op, Args...>;

I tratti per rilevare la presenza del metodo possono quindi essere implementati semplicemente:

typename <typename T, typename ...Ts>
using foo_type = decltype(std::declval<T>().foo(std::declval<Ts>()...));

struct C1 {};

struct C2 {
    int foo(char) const;
};

template <typename T>
using has_foo_char = is_detected<foo_type, T, char>;

static_assert(!has_foo_char<C1>::value, "Unexpected");
static_assert(has_foo_char<C2>::value, "Unexpected");

static_assert(std::is_same<int, detected_t<foo_type, C2, char>>::value,
              "Unexpected");

static_assert(std::is_same<void, // Default
                           detected_or<void, foo_type, C1, char>>::value,
              "Unexpected");
static_assert(std::is_same<int, detected_or<void, foo_type, C2, char>>::value,
              "Unexpected");

Risoluzione di sovraccarico con un gran numero di opzioni

Se è necessario selezionare tra diverse opzioni, abilitare solo uno tramite enable_if<> può essere piuttosto ingombrante, poiché anche diverse condizioni devono essere negate.

L'ordine tra sovraccarichi può invece essere selezionato usando l'ereditarietà, cioè l'invio di tag.

Invece di testare la cosa che deve essere ben formata, e anche testare la negazione di tutte le altre condizioni delle versioni, decltype invece solo ciò di cui abbiamo bisogno, preferibilmente in un decltype in un ritorno finale.
Ciò potrebbe lasciare diverse opzioni ben formate, differenziamo tra quelle che usano i 'tag', simili ai tag iterator-trait ( random_access_tag et al). Funziona perché una corrispondenza diretta è migliore di una classe base, che è migliore di una classe base di una classe base, ecc.

#include <algorithm>
#include <iterator>

namespace detail
{
    // this gives us infinite types, that inherit from each other
    template<std::size_t N>
    struct pick : pick<N-1> {};
    template<>
    struct pick<0> {};

    // the overload we want to be preferred have a higher N in pick<N>
    // this is the first helper template function
    template<typename T>
    auto stable_sort(T& t, pick<2>)
        -> decltype( t.stable_sort(), void() )
    {
        // if the container have a member stable_sort, use that
        t.stable_sort();
    }

    // this helper will be second best match
    template<typename T>
    auto stable_sort(T& t, pick<1>)
        -> decltype( t.sort(), void() )
    {
        // if the container have a member sort, but no member stable_sort
        // it's customary that the sort member is stable
        t.sort();
    }

    // this helper will be picked last
    template<typename T>
    auto stable_sort(T& t, pick<0>)
        -> decltype( std::stable_sort(std::begin(t), std::end(t)), void() )
    {
        // the container have neither a member sort, nor member stable_sort
        std::stable_sort(std::begin(t), std::end(t));
    }

}

// this is the function the user calls. it will dispatch the call
// to the correct implementation with the help of 'tags'.
template<typename T>
void stable_sort(T& t)
{
    // use an N that is higher that any used above.
    // this will pick the highest overload that is well formed.
    detail::stable_sort(t, detail::pick<10>{});
}

Esistono altri metodi comunemente usati per distinguere tra sovraccarichi, ad esempio la corrispondenza esatta è migliore della conversione, essendo migliore dei puntini di sospensione.

Tuttavia, il tag-dispatch può estendersi a qualsiasi numero di scelte ed è un po 'più chiaro nell'intento.