如何在C++组合模式中用Concepts而非CRTP强制接口？

构造函数内static_assert的可行性 #

用构造函数内的static_assert替代模板上的Concept约束，是能绕过当前编译错误的可行方案，但绝非符合C++20 Concepts设计初衷的“正确”实现方式。

该方案的核心弊端 #

• 错误触发时机过晚：模板参数上的Concept约束会在模板实例化阶段（甚至更早的概念匹配阶段）就触发错误，哪怕你只是声明了A<B>但从未构造对象。而static_assert仅在构造函数被实际调用时才会检查，若代码中只声明了A<B>变量却未初始化，错误会被隐藏到编译后期，增加调试成本。
• 无法覆盖所有模板使用场景：如果A包含静态成员函数或其他非构造阶段调用的成员，这些代码依赖B的接口时，static_assert无法约束——因为静态成员可能在构造对象前就被调用，此时仍会因B的接口问题报错，且没有Concept的提前检查提示。
• 丧失Concept的文档性与重载能力：Concept作为模板参数约束，本身就是代码文档，看template<HasBar T> class A就能直观知道T需要满足的接口；同时Concept可参与重载决议，让编译器自动匹配符合约束的模板版本。static_assert只是事后检查，无法提供这些特性。
• 错误信息不够直观：Concept的编译错误通常会明确指出“B不满足HasBar约束：未找到成员函数bar()”这类精准提示，而static_assert需要你手动编写错误信息，若描述模糊，用户很难快速定位问题根源。

更优的解决思路 #

你遇到的不完全类型问题，本质是模板类声明阶段B还未完成定义，导致Concept无法检查其接口。正确的做法是将Concept约束延迟到实际使用B接口的成员函数上，而非模板类的参数层面：

示例代码 #

#include <concepts>

// 定义HasBar概念
template<typename T>
concept HasBar = requires(T t) {
    { t.bar() } -> std::same_as<void>;
};

// 模板类A不直接在参数上约束Concept
template <typename T>
class A {
public:
    // 仅在需要调用bar()的成员函数上添加Concept约束
    void invoke_bar() requires HasBar<T> {
        m_t.bar();
    }

    // 若构造函数需要调用bar()，也可在构造函数上添加约束
    A() requires HasBar<T> {
        m_t.bar();
    }

private:
    T m_t;
};

// 先声明B，再定义A<B>（此时B是不完全类型，但Concept约束在成员函数，不会报错）
class B;
A<B> a;

// 定义B，满足HasBar概念
class B {
public:
    void bar() {}
};

int main() {
    a.invoke_bar(); // 此时B已完全定义，Concept检查通过
    return 0;
}

这种方式既保留了Concept的所有优势，又完美解决了不完全类型的问题。

内容的提问来源于stack exchange，提问作者user5406764