C++
SFINAE (Vervangingsfout is geen fout)

enable_if

std::enable_if is een handig hulpprogramma om booleaanse voorwaarden te gebruiken om SFINAE te activeren. Het is gedefinieerd als:

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

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

Dat wil zeggen, enable_if<true, R>::type is een alias voor R , terwijl enable_if<false, T>::type slecht gevormd is omdat die specialisatie van enable_if geen type enable_if heeft.

std::enable_if kan worden gebruikt om sjablonen te beperken:

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

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

Hier zou een oproep tot negate(1) mislukken vanwege dubbelzinnigheid. Maar de tweede overbelasting is niet bedoeld om te worden gebruikt voor integrale typen, dus we kunnen toevoegen:

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(); }

Nu, het negate<int> zou resulteren in een substitutiefout omdat !std::is_arithmetic<int>::value false . Vanwege SFINAE is dit geen harde fout, deze kandidaat wordt eenvoudig uit de overbelastingsset verwijderd. Als gevolg hiervan heeft negate(1) slechts één enkele levensvatbare kandidaat - die vervolgens wordt genoemd.

Wanneer gebruiken

Het is de moeite waard om in gedachten te houden dat std::enable_if een hulp is bovenop SFINAE, maar het is niet wat SFINAE in de eerste plaats laat werken. Laten we deze twee alternatieven overwegen voor het implementeren van functionaliteit die vergelijkbaar is met std::size , dat wil zeggen een overload set size(arg) die de grootte van een container of array produceert:

// 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]);

Ervan uitgaande dat is is_sizeable is correct geschreven, moeten deze twee verklaringen precies gelijk zijn met betrekking tot SFINAE. Wat is het gemakkelijkst om te schrijven en wat is het gemakkelijkst om in één oogopslag te beoordelen en te begrijpen?

Laten we nu eens kijken hoe we rekenkundige helpers willen implementeren die een ondertekende overloop van integers vermijden ten gunste van wrap-around of modulair gedrag. Dat wil zeggen dat bijvoorbeeld incr(i, 3) hetzelfde zou zijn als i += 3 behalve dat het resultaat altijd zou worden gedefinieerd, zelfs als i een int met waarde INT_MAX . Dit zijn twee mogelijke alternatieven:

// 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);

Nogmaals, wat is het gemakkelijkst om te schrijven, en wat is het gemakkelijkst te beoordelen en in één oogopslag te begrijpen?

Een sterkte van std::enable_if is hoe het speelt met refactoring en API-ontwerp. Als is_sizeable<Cont>::value bedoeld is om aan te geven of cont.size() geldig is, dan kan alleen het gebruik van de uitdrukking zoals die voor size1 verschijnt beknopter zijn, hoewel dat kan afhangen van of is_sizeable op verschillende plaatsen zou worden gebruikt of niet . std::is_signed dat met std::is_signed dat zijn intentie veel duidelijker weergeeft dan wanneer de implementatie ervan lekt in de declaratie van 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?

volgde DEC-type in functiesjablonen

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);
}

Wat is SFINAE

SFINAE staat voor S ubstitution F ailure I s N ot A n E rror. Onjuist gevormde code die het gevolg is van het vervangen van typen (of waarden) om een functiesjabloon of klassensjabloon te instantiëren, is geen harde compileerfout, het wordt alleen behandeld als een aftrekfout.

Aftrekfouten bij instantiërende functiesjablonen of klassensjabloonspecialisaties verwijderen die kandidaat uit de reeks van overweging - alsof die mislukte kandidaat in eerste instantie niet bestond.

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. 

Alleen substitutiefouten in de onmiddellijke context worden beschouwd als aftrekfouten, alle andere worden beschouwd als harde fouten.

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

Om type_trait creatie generaliseren: gebaseerd op SFINAE er experimentele eigenschappen detected_or , detected_t , is_detected .

Met sjabloonparameters typename Default , template <typename...> Op en typename ... Args :

• is_detected : alias van std::true_type of std::false_type afhankelijk van de geldigheid van Op<Args...>
• detected_t : alias van Op<Args...> of nonesuch afhankelijk van de geldigheid van Op<Args...> .
• detected_or : alias van een structuur met value_t die is_detected , en type dat is Op<Args...> of Default , afhankelijk van de geldigheid van Op<Args...>

die kan worden geïmplementeerd met std::void_t voor SFINAE als volgt:

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...>;

Kenmerken om de aanwezigheid van de methode te detecteren, kunnen vervolgens eenvoudig worden geïmplementeerd:

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");

Overbelastingsresolutie met een groot aantal opties

Als u tussen verschillende opties moet kiezen, kan het inschakelen van slechts één via enable_if<> behoorlijk omslachtig zijn, omdat verschillende voorwaarden ook moeten worden genegeerd.

De volgorde tussen overbelastingen kan in plaats daarvan worden geselecteerd met behulp van overerving, dwz tagverzending.

In plaats van te testen op het ding dat goed moet zijn gevormd, en ook het testen van de ontkenning van alle voorwaarden van de andere versies, testen we in plaats daarvan alleen wat we nodig hebben, bij voorkeur in een decltype in een achterstand.
Dit kan verschillende opties goed gevormd laten, we maken een onderscheid tussen die met 'tags', vergelijkbaar met iterator-trait tags ( random_access_tag et al). Dit werkt omdat een directe match beter is dan een basisklasse, wat beter is dan een basisklasse van een basisklasse, enz.

#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>{});
}

Er zijn andere methoden die gewoonlijk worden gebruikt om onderscheid te maken tussen overbelastingen, zoals exact zoeken beter is dan conversie, beter dan ellips.

Tag-verzending kan zich echter uitstrekken tot een willekeurig aantal keuzes en is wat duidelijker van opzet.