Warum sollten Sie die Verwendung von „std::enable_if“ in Funktionsrückgabetypen vermeiden?

Warum sollte man std::enable_if in Funktionssignaturen vermeiden?

std::enable_if, ein vielseitiges Tool in C, kann verwendet werden auf verschiedene Arten, um Funktionen oder Klassen basierend auf bestimmten Kriterien bedingt zu definieren. Scott Meyers hat jedoch davor gewarnt, es in Funktionssignaturen zu verwenden. Um diese Empfehlung zu verstehen, müssen die verschiedenen mit std::enable_if verfügbaren Strategien und ihre Auswirkungen untersucht werden.

Implementierungsoptionen:

1. Funktionsparameter:

<code class="cpp">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; }   
};</code>

2. Vorlagenparameter:

<code class="cpp">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; }   
};</code>

3. Rückgabetyp:

<code class="cpp">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;
    }   
};</code>

Bevorzugter Ansatz:

Der günstigste Ansatz besteht darin, das enable_if in den Vorlagenparametern zu platzieren. Diese Technik bietet Vorteile sowohl hinsichtlich der Klarheit als auch der Vielseitigkeit.

Klarheit:

Die Klausel „enable_if“ kann von den Rückgabe- und Argumenttypen getrennt gehalten werden, was zu besser lesbarem Code führt. Selbst mit der Verwendung von Alias-Vorlagen zur Reduzierung der Unordnung kombinieren die zusammengeführten Klauseln in den anderen Ansätzen immer noch separate und unterschiedliche Konzepte.

Vielseitigkeit:

Diese Technik kann universell eingesetzt werden Wird auf verschiedene Kontexte angewendet, einschließlich Konstruktoren ohne Rückgabetypen und Operatoren, die zusätzliche Argumente verbieten. SFINAE, der Schlüssel hinter dem bedingten Verhalten von std::enable_if, ist nur auf Vorlagen anwendbar und unterstützt die Universalität dieses Ansatzes weiter.

Vermeidung von std::enable_if in Rückgabetypen:

Bei der Verwendung von std::enable_if in Rückgabetypen liegt das Problem nicht an der Funktionssignatur, sondern an den Vorlagenspezialisierungen. Meyers rät aus Gründen der Klarheit und Konsistenz von dieser Praxis ab. Die Angabe von Rückgabetypen mit „enable_if“ führt zu Inkonsistenzen zwischen Vorlagendefinitionen und der Basisvorlage:

<code class="cpp">template<typename T>
struct Check4
{
    typename std::enable_if<std::is_same<T, int>::value, int>::type read() {
        return 42;
    }

    int read() {    // error: redeclared without 'typename'
        return 3.14;  // never used
    }   
};</code>

Member- und Nicht-Member-Funktionsvorlagen:

Die besprochenen Bedenken und Empfehlungen gelten sowohl für Member- als auch für Nicht-Member-Funktionsvorlagen. Es gibt keine nennenswerten Unterschiede im Ansatz.

Das obige ist der detaillierte Inhalt vonWarum sollten Sie die Verwendung von „std::enable_if“ in Funktionsrückgabetypen vermeiden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!