Master Compile‑Time Polymorphism: Ditch Obscure SFINAE with C++20 Concepts

Understanding Compile‑Time Polymorphism

Runtime polymorphism relies on virtual functions and incurs a small runtime cost, while compile‑time polymorphism performs all type checks, logic branches, and interface constraints during compilation, yielding zero runtime overhead. It is essential for high‑performance generic components, STL containers, and algorithms.

All type decisions happen at compile time.

Zero runtime cost, performance matches hand‑written code.

Used to constrain template types, select overloads, and differentiate logic.

Invalid types are rejected early, preventing runtime crashes.

Traditional SFINAE: Powerful but Hard to Read

SFINAE (Substitution Failure Is Not An Error) lets the compiler discard an overload when template substitution fails, enabling type‑based branching. The following example extracts whether a type has an Update() method:

#include <type_traits>
#include <iostream>

// SFINAE extraction: check if type has Update()
template<typename T, typename = void>
struct HasUpdate : std::false_type {};

template<typename T>
struct HasUpdate<T, std::void_t<decltype(std::declval<T>().Update())>> : std::true_type {};

// Overload based on SFINAE
template<typename T>
std::enable_if_t<HasUpdate<T>::value, void> Process(T& obj) {
    obj.Update();
    std::cout << "拥有 Update 方法，执行更新逻辑
";
}

template<typename T>
std::enable_if_t<!HasUpdate<T>::value, void> Process(T& obj) {
    std::cout << "无 Update 方法，执行默认逻辑
";
}

// Test structs
struct A { void Update() {} };
struct B {};

int main() {
    A a; B b;
    Process(a);
    Process(b);
    return 0;
}

Four major pain points of SFINAE are highlighted:

Unreadable syntax : heavy use of std::declval, decltype, std::void_t, std::enable_if_t makes code opaque.

Cryptic error messages : failed substitutions generate long template‑stack traces that are hard to locate.

Poor scalability : nesting multiple constraints quickly explodes code size and error‑proneness.

Implicit semantics : SFINAE is a passive match; the intent of a constraint is not obvious from the code.

Concepts: Modern Solution

C++20 introduced Concepts , a syntactic‑sugar and semantic layer built on top of SFINAE. Concepts retain zero‑cost compile‑time matching while solving readability, error‑reporting, and extensibility issues.

Intuitive semantics : constraints read like documentation.

Precise errors : the compiler reports exactly which concept is not satisfied.

Logical composition : &&, ||, and ! combine constraints cleanly.

Zero overhead : still evaluated at compile time.

Equivalent refactoring of the previous SFINAE example using Concepts dramatically reduces code size and clarifies intent:

#include <concepts>
#include <iostream>

// Custom Concept: type must have Update()
template<typename T>
concept HasUpdate = requires(T t) {
    t.Update();
};

// Constrained function template
template<HasUpdate T>
void Process(T& obj) {
    obj.Update();
    std::cout << "拥有 Update 方法，执行更新逻辑
";
}

// Overload for non‑constrained types
template<typename T>
void Process(T& obj) {
    std::cout << "无 Update 方法，执行默认逻辑
";
}

// Test structs
struct A { void Update() {} };
struct B {};

int main() {
    A a; B b;
    Process(a);
    Process(b);
    return 0;
}

The difference is evident: the original dozens of lines of nested SFINAE become a few clear statements.

Precise Error Example

Passing a type that violates the HasUpdate concept yields an immediate, readable diagnostic:

error: constraint not satisfied
   note: concept ‘HasUpdate’ was not satisfied

This transforms the “template‑stack nightmare” of SFINAE into a straightforward constraint failure.

Deep Comparison: SFINAE vs Concepts

Code readability : SFINAE – extremely poor; Concepts – excellent, self‑documenting.

Compilation error experience : SFINAE – massive stack traces; Concepts – precise, constraint‑specific messages.

Multi‑condition constraints : SFINAE – nested, error‑prone; Concepts – logical operators allow concise expressions.

Semantic expression : SFINAE – passive matching; Concepts – active, explicit constraints.

Runtime overhead : both zero, as all work happens at compile time.

Engineering practicality : SFINAE – legacy fallback; Concepts – preferred for modern projects, easier maintenance.

Advanced Concepts Example: Complex Multi‑Condition Constraint

Real‑world code often needs several simultaneous requirements. The following Concept combines an Update() method check, copyability, and non‑pointer status:

#include <concepts>
#include <iostream>

// Composite constraint
template<typename T>
concept ValidObject = requires(T t) {
    t.Update();
} && std::copyable<T> && !std::is_pointer_v<T>;

template<ValidObject T>
void GameLoop(T& obj) {
    obj.Update();
    std::cout << "游戏对象循环更新完成
";
}

// Valid type
struct Player {
    void Update() {}
};

// Invalid type (no Update)
struct EmptyObj {};

int main() {
    Player p;
    GameLoop(p); // compiles and runs
    // EmptyObj e;
    // GameLoop(e); // compile‑time error: constraint not satisfied
    return 0;
}

Implementing the same logic with SFINAE would roughly double the code size and re‑introduce the readability problems discussed earlier.

Underlying Mechanism

Concepts do not replace SFINAE; they are built on the same substitution‑failure mechanism. Concepts simply provide a higher‑level, standardized syntax that the compiler translates back into SFINAE‑style checks.

Conclusion

Compile‑time polymorphism trades compile‑time effort for zero runtime cost, a cornerstone of high‑performance C++ libraries. C++20 Concepts turn the once‑arcane SFINAE technique into a clear, maintainable tool that any developer can use effectively.